[{"content":"","date":"8 October 2026","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"Human-Computer Interaction coursework documented as a compact portfolio: observations, design reasoning, lab work, and the process behind each exercise.\n","date":"8 October 2026","externalUrl":null,"permalink":"/","section":"Course Portfolio","summary":"Human-Computer Interaction coursework documented as a compact portfolio: observations, design reasoning, lab work, and the process behind each exercise.\n","title":"Course Portfolio","type":"page"},{"content":"Course work is organised by module. Each page contains homework, lab notes, screenshots, and design reflections.\n","date":"8 October 2026","externalUrl":null,"permalink":"/courses/","section":"Courses","summary":"Course work is organised by module. Each page contains homework, lab notes, screenshots, and design reflections.\n","title":"Courses","type":"courses"},{"content":"","date":"8 October 2026","externalUrl":null,"permalink":"/tags/hci/","section":"Tags","summary":"","title":"HCI","type":"tags"},{"content":"Homework 2 covers three lecture tasks. I first looked at a current HCI researcher, then revisited an early vision of immersive computing, and finally analysed an alternative input device from an HCI perspective.\nLecture 4 — Present One HCI Researcher # Sidong Feng — Human, Software, and AI Interaction # For this task, I chose Dr. Sidong Feng, an Assistant Professor at the School of Data Science, The Chinese University of Hong Kong, Shenzhen.\nI chose him because his work is close to an area I am personally interested in: the connection between software engineering, HCI, large language models, and AI agents.\nHis recent research includes GUI automation, intelligent software testing, visual bug understanding, and agent-based interaction with user interfaces. What I find interesting is that these topics are no longer only about making software easier for humans to use. They also ask whether an AI agent can understand and operate the same interface.\nCurrent Research Projects # Three projects are good examples of the HCI side of his research.\nTowards Human-AI Synergy in UI Design: Supporting Iterative Generation with LLMs explores how LLMs can support an iterative UI design process while keeping the human designer involved in refinement.\nMUD: Towards a Large-Scale and Noise-Filtered UI Dataset for Modern Style UI Modeling focuses on building a large-scale, cleaner dataset of modern user interfaces for UI modelling.\nThese projects show that an AI system has to solve many problems that are usually natural for a human user:\nWhich object on the screen is interactive? What does an icon probably mean? What should I click next? Did the interface respond correctly? When should the AI continue, and when should it ask the human? Why I Think This Is an HCI Problem # Traditionally, I think of a graphical interface like this:\nHuman → Interface → Software\nWith an AI agent, the relationship can become:\nHuman → AI Agent → Interface → Software\nThis creates a new HCI layer. The interface is no longer only communicating with the person directly. The user may be giving an intention to an AI agent, while the agent operates the software on the user\u0026rsquo;s behalf.\nFor me, this raises questions about trust and control. If the AI clicks the wrong button, how does the user notice it? If the agent is uncertain, how should it show that uncertainty? If the user wants to take over, how easy should that be?\nThis is the main reason I chose Sidong Feng. His work shows that HCI is expanding as AI becomes more active inside software systems.\nReferences\nSidong Feng — CUHK-Shenzhen faculty profile Sidong Feng — personal research page Lecture 5 — The Ultimate Display # Reading Ivan Sutherland\u0026rsquo;s 1965 Vision Today # When I read Ivan Sutherland\u0026rsquo;s The Ultimate Display, the part that surprised me most was how modern the basic idea still feels.\nThe paper was written in 1965, but Sutherland was already thinking beyond a normal flat computer screen. He described the display more like a window into a computer-generated world, where the user could interact with things that do not have to follow the normal rules of the physical world.\nWhat Has Already Become Real? # A large part of the visual side of this idea already exists.\nModern VR and MR headsets can track head movement and update a stereoscopic 3D scene in real time. Hand tracking and motion controllers allow us to interact with virtual objects. Eye tracking is also becoming more common, and spatial audio can make a virtual environment respond to where the user is looking and moving.\nSo several parts of Sutherland\u0026rsquo;s vision are already normal technologies today:\nstereoscopic 3D displays, head tracking, hand and body tracking, eye tracking, motion controllers, spatial audio, basic haptic feedback. To me, this is already very close to his idea that the display should behave more like an environment than a static screen. Modern XR headsets make immersive 3D and spatially tracked experiences practical, while hand tracking lets users interact with virtual interfaces directly instead of relying only on physical controllers.\nWhat Is Still Missing? # The biggest missing part is physical feedback.\nA virtual object can now look very convincing, but it usually does not behave like a real object when I touch it.\nFor example, I can see a virtual chair, walk around it, and maybe even feel a vibration when my virtual hand reaches it. But I still cannot sit on it unless a real physical object exists in the same place.\nThis shows a clear gap between visual realism and physical realism.\nCurrent haptic devices can generate vibration, resistance, or limited force feedback, but they cannot freely create solid objects, weight, temperature, or texture anywhere in space. Haptic gloves are one current attempt to reduce this gap by adding physical feedback to virtual interaction.\nWhat Could Become Possible in the Future? # I do not think computers will literally create arbitrary physical matter in a room soon. A more realistic path is to combine several technologies.\nFor example, future XR systems could use:\nlighter haptic gloves, wearable force-feedback devices, robotic or shape-changing surfaces, better room-scale tracking, redirected walking, AI-generated interactive environments. The system would not need to create a real virtual object. It only needs to provide the right physical response at the right time.\nFor me, that would be a practical step toward Sutherland\u0026rsquo;s “ultimate display”.\nThe most impressive thing about this paper is therefore not one exact prediction. It is the idea that the interface could eventually become so natural that the user feels like they are interacting with a world rather than operating a computer.\nReading\nIvan E. Sutherland — The Ultimate Display Lecture 6 — Input Devices and Interaction Paradigms # The Vertical Ergonomic Mouse # For this task, I chose the vertical ergonomic mouse. The main change is not the cursor mapping, but the posture of the hand and forearm.\nI would not call it a completely failed product because vertical mice are still sold and used today. I think it is more interesting to look at it as an alternative input device that has existed for many years but has never replaced the conventional flat mouse.\nThat leads to a simple HCI question:\nIf the ergonomic idea makes sense, why do most people still use a normal mouse?\nClassification # From an interaction point of view, the vertical mouse is still a normal GUI pointing device.\nI would classify it as:\na physical input device, an indirect input device, a continuous 2D pointing device, mainly used with a graphical user interface. The cursor mapping is almost unchanged. Moving the mouse still moves the pointer, while buttons and the scroll wheel provide discrete actions.\nThe important change is the posture of the user\u0026rsquo;s hand and forearm.\nThe Ergonomic Idea # With a normal flat mouse, the palm faces downward and the forearm is more pronated. A vertical mouse rotates the hand toward a more neutral, handshake-like position.\nResearch supports part of this idea. One study comparing a standard and a vertical mouse found that the vertical design reduced forearm pronation and lowered activity in some wrist extensor muscles.\nHowever, the same study also found that users took longer to reach targets with the vertical mouse.\nThis trade-off is what makes the example interesting to me: an input device can improve one part of the experience while making another part worse.\nAnother study comparing flat, angled, and vertical mice found that fully vertical designs reduced pronation, but the fully vertical mouse also produced the poorest pointing performance. Angled designs gave some of the postural benefit without the same performance loss.\nWhy Has It Not Replaced the Normal Mouse? # I think the first reason is muscle memory.\nMost users have spent years using a flat mouse. Even if the cursor mapping is identical, changing the orientation of the hand changes the way small movements are produced.\nThe second reason is precision and speed. For gaming, CAD, image editing, or other tasks that require quick and accurate pointing, users may prefer a device they already know very well.\nThe third reason is fit. A vertical mouse usually depends strongly on hand size and handedness. A shape that feels comfortable for one person may feel awkward for another.\nThere is also a more general lesson here: calling something “ergonomic” does not automatically make it the best interface for every user.\nComfort, performance, familiarity, learning time, and task type all matter at the same time.\nWill It Succeed in the Future? # I think vertical mice will continue to exist, but mainly as an alternative, not as a universal replacement.\nFor office users who spend many hours using a mouse, reduced forearm pronation may be worth a short learning period.\nFor other users, the traditional mouse may still provide the best balance of speed, size, familiarity, and control.\nThe future may therefore be less about choosing between a completely flat mouse and a completely vertical mouse. A more realistic direction may be slanted or adjustable designs that try to balance ergonomics with familiar pointing performance.\nFor me, this example shows a very clear HCI trade-off:\nbetter physical posture does not automatically mean better overall interaction.\nReferences\nQuemelo \u0026amp; Vieira (2013) — Biomechanics and performance when using a standard and a vertical computer mouse Odell \u0026amp; Johnson (2015) — Evaluation of flat, angled, and vertical computer mice Gaudez \u0026amp; Cail (2016) — Effects of mouse slant and desktop position Conclusion # These three tasks gave me three different views of HCI.\nSidong Feng\u0026rsquo;s work shows how interfaces are changing because AI agents can now become active participants in software interaction. Sutherland\u0026rsquo;s The Ultimate Display shows that many ideas behind modern VR and MR were already imagined decades ago. The vertical mouse shows that even a small change in a familiar input device can create a trade-off between comfort, performance, and learning cost.\nFor me, the common point is that HCI is not only about making an interface look better. It is about understanding how people, devices, software, and increasingly AI systems interact with each other.\n","date":"8 October 2026","externalUrl":null,"permalink":"/courses/hci/homework-2/","section":"Courses","summary":"Lecture 4–6: an HCI researcher, The Ultimate Display, and the vertical ergonomic mouse.","title":"HCI — Homework 2","type":"courses"},{"content":"","date":"8 October 2026","externalUrl":null,"permalink":"/tags/homework/","section":"Tags","summary":"","title":"Homework","type":"tags"},{"content":"","date":"8 October 2026","externalUrl":null,"permalink":"/tags/human-ai-interaction/","section":"Tags","summary":"","title":"Human-AI Interaction","type":"tags"},{"content":"","date":"8 October 2026","externalUrl":null,"permalink":"/categories/human-computer-interaction/","section":"Categories","summary":"","title":"Human-Computer Interaction","type":"categories"},{"content":"This section documents my HCI homework and lab exercises. Each entry focuses on a concrete example, the relevant interaction-design principle, and the reasoning behind a redesign.\n","date":"8 October 2026","externalUrl":null,"permalink":"/courses/hci/","section":"Courses","summary":"This section documents my HCI homework and lab exercises. Each entry focuses on a concrete example, the relevant interaction-design principle, and the reasoning behind a redesign.\n","title":"Human-Computer Interaction","type":"courses"},{"content":"","date":"8 October 2026","externalUrl":null,"permalink":"/tags/input-devices/","section":"Tags","summary":"","title":"Input Devices","type":"tags"},{"content":"","date":"8 October 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"8 October 2026","externalUrl":null,"permalink":"/tags/xr/","section":"Tags","summary":"","title":"XR","type":"tags"},{"content":"","date":"1 October 2026","externalUrl":null,"permalink":"/tags/affordance/","section":"Tags","summary":"","title":"Affordance","type":"tags"},{"content":"","date":"1 October 2026","externalUrl":null,"permalink":"/tags/blowfish/","section":"Tags","summary":"","title":"Blowfish","type":"tags"},{"content":"","date":"1 October 2026","externalUrl":null,"permalink":"/tags/dark-patterns/","section":"Tags","summary":"","title":"Dark Patterns","type":"tags"},{"content":"","date":"1 October 2026","externalUrl":null,"permalink":"/tags/gestalt-laws/","section":"Tags","summary":"","title":"Gestalt Laws","type":"tags"},{"content":"","date":"1 October 2026","externalUrl":null,"permalink":"/tags/github-pages/","section":"Tags","summary":"","title":"GitHub Pages","type":"tags"},{"content":" Introduction # This homework explores three foundational topics in human-computer interaction: affordances, Gestalt laws, and dark design patterns. Rather than treating them only as definitions, I use everyday objects and digital interfaces to examine how design influences expectation, perception, and decision-making.\nThe goal is not simply to label a design as good or bad. The more useful question is whether the design communicates the intended action clearly, whether visual elements are organised in a way that matches the user\u0026rsquo;s perception, and whether the interface supports the user\u0026rsquo;s own goal instead of steering them toward another one.\n1. Affordances # Affordance describes how the properties of an object suggest possible actions to a user. A clear affordance makes an interaction easy to infer before any instruction is read. A weak affordance creates uncertainty between what the user expects to happen and what the product actually requires.\n1.1 Clear Affordance — Traditional Screwdriver # Figure 1. Traditional screwdrivers provide strong visual and physical cues for grasping, aligning, and turning.\nThe traditional screwdriver is a strong example of clear affordance because most of its intended use can be inferred directly from its physical form.\nThe enlarged handle invites the hand to grasp it. Its rounded and slightly contoured shape supports a stable grip and suggests that rotational force should be applied through twisting. The long metal shaft establishes an obvious axis between the hand and the screw, while the visible tip indicates where the tool should contact the screw head.\nThe mapping between action and result is also direct. When the user rotates the handle, the tip rotates by the same amount and in the same direction. There is no hidden operating mode between the user\u0026rsquo;s movement and the mechanical result. This makes the interaction easy to understand even before the tool is used.\nDifferent tip shapes provide another immediate visual cue about compatibility. A Phillips tip visually corresponds to a cross-shaped screw head, while a slotted tip corresponds to a straight slot. The tool therefore communicates both where to hold it and where to apply it.\nWhy the affordance is clear:\nThe handle shape visibly and physically supports grasping. The shaft establishes a clear direction of use. The tip shape communicates compatibility with the screw head. Hand rotation maps directly to tip rotation. Mechanical resistance is felt immediately through the handle, providing continuous feedback. 1.2 Ambiguous Control Affordance — Electric Screwdriver # Figure 2. The electric screwdriver preserves the basic screwdriver form, but its added controls make the detailed interaction less self-explanatory.\nThe electric screwdriver is not a bad product overall. Its general purpose is still recognisable from the bit and handheld form. The weaker affordance appears in its control interface.\nSeveral controls are placed along the same visual strip on the body. A round button uses a familiar power symbol, while a second elongated control uses curved markings related to rotation. For a first-time user, however, the relationship between these controls is not immediately obvious. It may be unclear whether the round button turns the device on, starts the motor, or changes a mode. The second control suggests direction, but the markings do not provide a strong spatial mapping to clockwise and counter-clockwise rotation.\nThe collar near the bit introduces another adjustable function. This is useful once the product is understood, but it adds another layer of interpretation before the basic interaction is fully clear. Compared with the manual screwdriver, more of the operating logic is hidden inside the device and must be learned from symbols or previous experience.\nThe problem is therefore not that an electric screwdriver is inherently a poor design. The problem is that the individual roles of its controls are less obvious to a new user.\nWhy the affordance is weaker:\nMultiple controls have similar visual importance even though they perform different functions. The primary start/stop action is less physically obvious than a trigger placed under the index finger. Rotation direction depends on interpreting symbols rather than an obvious physical mapping. Additional modes increase the amount of knowledge required before first use. A new user may need to experiment before understanding which control produces which result. 1.3 Redesign Proposal # I would keep the compact electric form but separate the main actions more clearly.\nFirst, motor activation should be moved to an index-finger trigger. Its position would itself suggest pressing, and the user could activate the motor while maintaining a stable grip.\nSecond, forward and reverse should use a two-sided thumb switch marked with explicit clockwise and counter-clockwise arrows. The two directions should be physically separated so the control itself reflects the two possible rotational outcomes.\nThird, torque or mode adjustment should remain near the front collar, but the settings should use clear detents and visible labels such as 1–5 and MAX. This separates continuous tool operation from occasional configuration.\nFinally, the controls should differ in both shape and position, not only in printed symbols. A user should be able to distinguish the trigger, direction switch, and mode control by touch as well as by sight.\nInteraction Traditional screwdriver Current electric screwdriver Proposed electric screwdriver Start action Grip and turn Requires interpreting controls Index-finger trigger Direction Directly follows hand rotation Symbol-based control Two-sided clockwise/counter-clockwise switch Mode selection None Additional control near the front Clearly labelled detented collar Feedback Direct mechanical resistance Partly mediated by the motor Motor response plus clear direction/mode indication Learning required Very low Moderate for a first-time user Reduced through physical mapping 2. Gestalt Laws # Gestalt laws describe how people organise visual information into meaningful groups and structures. Instead of perceiving every visual element independently, users naturally infer relationships from proximity, similarity, enclosure, continuity, closure, and figure-ground separation.\nThe following two examples show situations where this automatic organisation can produce confusion because the visual design does not match the intended interpretation.\n2.1 Figure–Ground — Removable Laptop Screen Film # Figure 3. The transparent layer covers almost exactly the same area as the display, making the temporary film visually merge with the screen.\nThis example illustrates a problem with the Gestalt principle of figure–ground.\nA temporary transparent film can be placed over a laptop display during packaging or shipping. The film covers the same rectangular region as the screen, has very little colour contrast, and visually resembles a normal protective surface. Because of these similarities, the film may not initially be perceived as a separate foreground object.\nThe user can therefore interpret the film in two different ways: as temporary packaging that should be removed, or as a permanent protective layer that should remain on the screen. The lifted corner provides a peeling cue, but the rest of the transparent surface still visually merges with the display.\nThe design problem is therefore not simply that some users choose not to remove the film. The problem is that the visual separation between temporary layer and actual screen is weaker than it could be.\nCorrection # The temporary film should be visually separated from the display more clearly. Possible changes include:\na coloured pull tab, a visible printed border, large text such as “Remove before use”, or a temporary pattern printed on the film. These changes would make the film stand out as a separate figure instead of visually merging with the screen underneath.\n2.2 Similarity and Figure–Ground — Canva Website Builder Landing Page # Figure 4. The product demonstration contains controls that strongly resemble the real interactive controls of the surrounding page.\nThe large product demonstration on this landing page is useful because it shows what the website editor looks like. However, it also creates a visual ambiguity.\nInside the demonstration are elements that look like real controls: Preview, Publish Website, Share, icons, a profile button, navigation tools, and a large BOOK A TABLE button. These elements use the same visual language as normal interactive web controls: borders, filled button backgrounds, icons, and labels.\nThis creates a similarity problem. Elements inside the static demonstration resemble elements that users normally expect to be clickable. At the same time, the demonstration occupies a large central region and is visually integrated into the landing page, which weakens the figure–ground distinction between the real website and the interface being demonstrated.\nA user may therefore need a moment to determine which controls belong to the current page and which are only part of the product preview.\nCorrection # The demonstration could be made more clearly representational by:\nadding a small label such as “Editor preview”, placing the demonstration inside a stronger device/window frame, slightly reducing the contrast of controls inside the preview, or adding a subtle background separation between the live landing page and the example interface. The goal is not to make the demonstration less attractive. It is to make the boundary between interactive page and example interface immediately clear.\n3. Dark Design Patterns # Dark design patterns are interface strategies that steer users toward actions they may not otherwise choose. They exploit attention, hesitation, visual hierarchy, or persistence rather than supporting an equally clear and informed choice.\nThe two examples below use simplified reconstructions of common web patterns so that the design problem and the redesign can be compared directly.\n3.1 Interface Interference — Unequal Cookie Choices # Figure 5. A simplified reconstruction of interface interference: accepting all cookies is made visually dominant while rejecting is reduced to a low-emphasis text action.\nA common dark pattern appears in cookie consent banners. The Accept All action may be large, filled, and high-contrast, while Reject All is presented as a small text link or hidden behind additional settings.\nThis is a form of interface interference because the visual hierarchy privileges one decision over another. The website is still technically offering a choice, but the two options are not presented with equal salience or effort.\nThe problem is not the request for consent itself. The problem is that the interface makes the website\u0026rsquo;s preferred outcome easier to notice and easier to select.\nRedesign — Equal Choice # Figure 6. Redesign: accepting and rejecting are presented at the same level, while detailed preferences remain available as a third option.\nThe redesign gives Accept All and Reject All equal visual weight and keeps both actions on the first layer. Manage Preferences remains available without being used to hide the rejection path.\nThis changes the interaction from persuasion toward a particular answer to a clearer expression of user choice.\n3.2 Nagging — Repeated Newsletter Pop-up # Figure 7. A simplified reconstruction of nagging: the same sign-up request returns after the user has already dismissed it.\nAnother common dark pattern is a newsletter or account sign-up prompt that repeatedly returns after the user has already dismissed it.\nA single invitation is not necessarily problematic. The dark pattern appears when the interface does not respect the user\u0026rsquo;s previous response and repeatedly interrupts the original task. The user\u0026rsquo;s goal may be to read an article or browse information, while the system keeps redirecting attention toward registration or email capture.\nThis is nagging because the redirection persists across interactions. If the pop-up also blocks access to the underlying task until the user responds, it can additionally resemble forced action.\nRedesign — Remember the User\u0026rsquo;s Decision # Figure 8. Redesign: the invitation is still available, but declining is clear and the choice is respected instead of repeatedly resurfacing.\nA user-respecting version should provide a visible No thanks option, remember the decision for a reasonable period, and avoid showing the same request again during the same session.\nThe objective is not to remove the website\u0026rsquo;s ability to invite users to subscribe. It is to preserve the invitation without turning persistence into pressure.\nConclusion # These examples show that usability depends not only on technical functionality, but also on how clearly a design communicates action, grouping, and intention.\nThe traditional screwdriver exposes most of its operating principle directly through physical form, while the electric screwdriver introduces useful functionality at the cost of additional interpretation. The laptop film and Canva landing page show how weak visual separation or excessive similarity can create perceptual ambiguity. Finally, the dark-pattern examples demonstrate how the same tools of visual hierarchy and interaction design can either support user autonomy or steer behaviour.\nAcross all three topics, the same lesson appears repeatedly: good interaction design reduces unnecessary uncertainty and makes the user\u0026rsquo;s options understandable without requiring extra interpretation or pressure.\n","date":"1 October 2026","externalUrl":null,"permalink":"/courses/hci/homework-1/","section":"Courses","summary":"Affordances, Gestalt laws, and dark design patterns examined through everyday tools and digital interfaces.","title":"HCI — Homework 1","type":"courses"},{"content":" Goal # The goal of this lab was to create an online course portfolio that I can update throughout the semester.\nI used Hugo as the static-site generator and Blowfish as the theme. The final website is published with GitHub Pages, so the coursework can be accessed through a normal public URL instead of only from a local development server.\nTools # Hugo Extended Blowfish Git GitHub Desktop GitHub Pages Process # I first installed Hugo Extended and created the website locally. I then organised the content into a simple course structure:\ncontent/ └── courses/ └── hci/ ├── homework-1/ ├── lab-1a/ └── lab-1b/ The site was configured as a compact academic portfolio rather than a general-purpose blog. I used a white background, restrained blue accents, thin separators, smaller article navigation, and lightweight hover transitions.\nFor local testing, I used:\nhugo server -D The website could then be previewed at:\nhttp://localhost:1313/ After the local version worked, I created the repository WanY864.github.io and used GitHub Desktop to upload the project. GitHub Actions then built the Hugo site and deployed it to GitHub Pages.\nProblems and Solutions # 1. Blowfish theme was not found # The first major problem occurred when Hugo reported:\nmodule \u0026#34;blowfish\u0026#34; not found The original setup attempted to install Blowfish as a Git submodule, but the repository did not contain a valid .gitmodules configuration. This caused the theme installation to fail even though the setup script continued running.\nI fixed this by changing the setup method so that Blowfish was downloaded directly into:\nthemes/blowfish This removed the dependency on Git submodules and made the project easier to move and publish.\n2. GitHub Desktop initially showed nothing to upload # The GitHub Pages repository already existed online, while my website files were stored in a different local folder. GitHub Desktop therefore had no changes to commit.\nI solved this by cloning the online repository with GitHub Desktop and then copying the website files into the cloned repository folder. After that, GitHub Desktop detected the files correctly and allowed me to commit and push them.\n3. GitHub Pages showed two deployment workflows # After the first upload, GitHub displayed both the custom Hugo workflow and the default Pages build process. The default process failed, but the custom Hugo workflow succeeded.\nThe important setting was:\nSettings → Pages → Build and deployment → Source → GitHub Actions The custom workflow successfully completed the build, artifact upload, and deployment stages.\nDesign Decisions # I wanted the website to feel closer to an academic course portfolio than a generic personal blog.\nThe main visual decisions were:\na clean white layout, compact typography, subtle blue divider lines, lightweight motion on links and content blocks, a smaller right-side table of contents, and direct navigation to course work. These choices keep the interface visually quiet while still giving the pages a clear hierarchy.\nWhat I Learned # This lab helped me understand the separation between three layers of a static website:\nContent — Markdown files and images. Theme — Blowfish controls much of the layout and visual structure. Generator and deployment — Hugo builds the site, while GitHub Pages publishes it. I also learned that a website that works locally is not automatically ready for deployment. Theme installation, repository structure, and the GitHub Pages build source all have to be configured correctly.\nThe final result is a reusable course portfolio that can be updated by adding new Markdown pages and pushing the changes to GitHub.\n","date":"1 October 2026","externalUrl":null,"permalink":"/courses/hci/lab-1a/","section":"Courses","summary":"Building and publishing my HCI course portfolio with Hugo, Blowfish, GitHub Desktop, and GitHub Pages.","title":"HCI — Lab 1A: Building My Course Website","type":"courses"},{"content":" Goal # The goal of this lab is to prepare the Unity development environment and create a first working 3D project.\nThe setup is kept separate from the website project so that Unity editors, downloads, and project files can be managed independently.\nEnvironment Structure # To keep large Unity files away from the system drive, I planned the following structure on drive D::\nD:\\Unity\\ ├── Editors\\ ├── Downloads\\ └── Projects\\ Unity Hub can remain installed normally, while the large Editor installations and project files can be placed on the secondary drive.\nSetup Procedure # The Unity setup workflow is:\nInstall Unity Hub. Sign in with a Unity account if required. Set the Unity Editor installation location to D:\\Unity\\Editors. Set the download/cache location to D:\\Unity\\Downloads. Install a stable Unity Editor version. Create a new 3D project inside D:\\Unity\\Projects. Open the project and inspect the main Unity panels. Add a simple 3D object to the scene. Change its position, rotation, and scale. Enter Play Mode and verify that the scene runs correctly. Main Unity Panels # For the first project, the most important parts of the interface are:\nHierarchy # The Hierarchy lists the objects currently contained in the scene.\nScene # The Scene view is the main workspace used to place and edit objects.\nInspector # The Inspector shows the properties and components of the selected object.\nGame # The Game view shows what the active camera outputs when the project runs.\nUnderstanding the difference between the Scene view and the Game view is important: the Scene view is used to build the environment, while the Game view represents the runtime result.\nFirst Project Checklist # The first project should contain at least:\none simple 3D object, a working camera, a light source, basic transform changes, and a successful Play Mode test. Documentation # The final lab evidence should include screenshots of:\nUnity Hub, the installed Unity Editor, the New Project window, the Unity Editor interface, the first 3D scene, and the project running in Play Mode. These screenshots provide direct evidence that the environment is installed and the first project is working.\nWhat I Learned # The main lesson from the setup process is that Unity becomes easier to understand when the interface is treated as a small workflow rather than as one large application:\nCreate object → Select object → Edit in Inspector → Arrange in Scene → Check in Game view → Run in Play Mode This workflow provides a clear starting point before moving on to more advanced interaction, scripting, or XR development.\n","date":"1 October 2026","externalUrl":null,"permalink":"/courses/hci/lab-1b/","section":"Courses","summary":"Preparing the Unity development environment and the workflow for my first 3D project.","title":"HCI — Lab 1B: Unity Setup","type":"courses"},{"content":"","date":"1 October 2026","externalUrl":null,"permalink":"/tags/hugo/","section":"Tags","summary":"","title":"Hugo","type":"tags"},{"content":"","date":"1 October 2026","externalUrl":null,"permalink":"/tags/lab/","section":"Tags","summary":"","title":"Lab","type":"tags"},{"content":"","date":"1 October 2026","externalUrl":null,"permalink":"/tags/unity/","section":"Tags","summary":"","title":"Unity","type":"tags"},{"content":"This website is a course portfolio for Human-Computer Interaction. It documents lecture-based homework and lab work as a sequence of short, visual case studies.\nThe goal is not only to present final results, but also to explain the design reasoning behind them: what I observed, which HCI principle is involved, why the design succeeds or fails, and how it could be improved.\n","externalUrl":null,"permalink":"/about/","section":"Course Portfolio","summary":"This website is a course portfolio for Human-Computer Interaction. It documents lecture-based homework and lab work as a sequence of short, visual case studies.\n","title":"About","type":"page"}]