My website :v

This site is built with SvelteKit, deployed to github pages using gh-pages and SvelteKit's adapter-static Hosted at https://goldentoaste.github.io

TODO

• Make a list and preview layout, for the Projects and Experiences tabs
• Add interactive demos/webtoys for certain javascript projects
• tweak the grid and vingette overlay some more, maybe add more post processing effects for even less visual clarity.
• improve svg divs to have a boolean to render inverted colors : filled instead of transparent background to ensure the icon is overall sqaure.
  • should debug why foreground and background colors are not transitioning for these divs.

Resources

• Elements taken from nier automata css: https://metakirby5.github.io/yorha/

• Platinum game's Ui Design blog post: https://www.platinumgames.com/official-blog/article/9624

• Colors taken from gruvbox-material, a vscode theme: https://github.com/sainnhe/gruvbox-material

• Technology icons: https://github.com/marwin1991/profile-technology-icons

• Help me write a retrospective self reflection on doing work relating ui prototyping, which i've been learning in human computer interaction class

• About 400 words

• Through my recent experience in the previous paper prototyping lab, I've decided the following for the different prototype fidelity:

  • Low fidelity, paper prototyping, sketches, and wireframes
    • I found hand drawn sketches and wireframes very effective at communicating ideas, and getting immediate feedback from users with some background context
    • I found proper paper prototyping not as effective as I initially expected, because they were more time consuming to produce than expected, and it's ability convey information depends too much on drawing quality, and is hard to make consistent when worked on by different team members
  • mid fidelity prototype and high level prototype, including designs with similar quality to the final product
    • Through my experience working on personal projects and volunteer work, as an non-professional designer individual, I found making higher quality /polished prototypes not time efficient
    • I prefer to code a prototypes of the functionalities I want to get feedback of, with reasonable(but not final) visual. Then tune the functionality according to feedback, then finalize visuals

• When working on the paper prototype, I think my team members shared similar sentiment as me

  • Paper prototype was time consuming as we weren't great at drawing
  • it was hard coordinate drawings consistency when pages were worked on by different members

• If I were to work on the paper prototype again with more time, I think I couldnve done better if it was better planned:

  • define the requirements more clearly
  • plan out the pages to be prototyped, in more details
  • discuss and plan a visual theme/style guide for the pages

• This experience relates to my volunteer work with a student club

  • Often worked with a design team when developing websites and applications
  • The figma designs were able to do very good job at representing the final project, and can get realistic and genuine feedback
  • Even though I don't see myself doing design work or making prototypes, I glad to be learning the prototype in class still, as I gain a better understand when working with and implementing designs.

Retrospective: Prototyping

Reflecting on my recent work with prototyping, particularly the paper prototyping lab, has changed my understanding of the design process. While prototyping is often used as a way to get a lowcost early feedback from users, my experience revealed that the effectiveness of a prototype is tied to its medium and the specific goals of the development phase.

Initially, I found low-fidelity sketches and wireframes to be highly effective for idea communication. They served as an good bridge between abstract ideas and user feedback, provided some context was established. However, my view toward formal paper prototyping shifted during the lab. My team and I found the process surprisingly time consuming. Because our drawing skills varied, the consistency across screens suffered, making it difficult to maintain a cohesive look and user experience. We find that the speed and effectiveness with paper prototypes depends on the designers' experience working with medium.

If I were to approach this again with more time, I would focus to first establish a clear visual style guide and more rigorous page planning before start drawing to ensure the requirements were consistent across the team. During the paper prototype lab, we had issues aligning aspects of the design, such as icon usages, ui element sizes on paper, significance of ui element colors, or how intractable features is indicated. And so if these things were established ahead of times, a lot of efforts would be saved during the drawing process.

My experience with mid/high fidelity prototypes was also mixed. In my volunteer work and personal projects, I've found that as a nonprofessional designer, spending excessive time on high fidelity visual mockups is often an inefficient use of time, because using dedicated design software also demands experience. With my web development experience, I prefer to coding a functional prototype with reasonable visuals to gather feedback, to allows for feedback on the actual interaction model. Once the functionality is validated, polishing and finalizing visuals can be worked on after.

This experience is relatable to my volunteer work with a student club, where I often apply my preferred workflow of prototyping and development. For example, when developing a custom web calendar component, I began with simple digital sketches to visual the rough layout; then moving immediately into a coded prototype with most of the functionalities, using a generic visual style. By building a functional demo, I feel like I can present other developers and designers with a more vivid sense of technical feasibility and intended user experience, instead of having to over explain how the component was supposed to work.

While I prefer this "code first" approach for my own tasks, working alongside design teams do make me feel the value a good Figma prototype brings. Their polish tends to bring much more realistic and genuine feedback because users tends to treat them as finished products. Even though I don't see myself doing much design work, this HCI coursework has been valuable in helping me understand the labor behind prototyping in paper and software. This experience has also helped me gain a much clearer vocabulary for discussing constraints and design concepts, which helps me in applying a more consistent transition from design to implementation.