Labels

Application Design Ⅱ / Final Project

7.11.2023 - 28.11.2023 (Week 11 - Week 14)
Takuto Hozumi / 0354047 / Bachelor Of Design (Hons) In Creative Media
Application Design Ⅱ
Final Project

LECTURE

All in-class lectures from week 1 to 7, including HTML/CSS Recap Exercise, and JavaScript Exercise are described in Task 1: App Design 1 Self-Evaluation and Reflection.

This project is a continuous project from Task 1 & Task 2.

INSTRUCTION

Process Work

I started by coding the first page in sequence. The logo page has a lot of movement, so we are structuring it from the logo animation, which introduces gsap, to the next screen, switching display: none; with JavaScript.



Fig.1-1: Logo Screen

Each screen is divided into sections, each with a separate ID.

Fig.1-2: Separated Sections

Fig.1-3: Screen switching function (JS)

During the creation process, there were some bugs such as CSS not working, and the html file itself had to be re-created several times.

Fig.1-4: Bug

The main page is created in the same way, starting from the top. I prepared all pages in a row and used the ID of each section to manage the behavior.

Fig.1-5: MainPage Coding

At some point, a single file contained more than 1,000 lines of code, which I managed using comment-outs. This includes notes in my native language, so there may be parts of the source code that you cannot read.

Fig.1-6: Screen Transition Control (JS)

In the process of creating these, I looked at the basics, such as inline and block elements, as well as detailed specifications about each code, for example, that query selectors are only targeted to one class.
Even though I could build the logic in my head and think I could implement it this way, it often didn't work.

Fig.1-7: Layout Management (CSS)

Margins and font size are managed by em, and screen size is set on a viewport basis. This is intended to match smartphones of various sizes.

Font design, button design, margins, and width ratio for two columns are numbered in classes for easy management, and templates are created in CSS.

Fig.1-8: Original Styles (CSS)

The boxes for managing margins were especially helpful in managing the layout, as they were ready to be called up and used immediately. However, it is also true that as code, it is not very pretty.

Fig.1-9: A Little Pushy Way

The naming system was actually confusing at times, so there is room for improvement. For example, if I were to create something next time, I could name the classes with different margins every 10px in order.

Fig.1-9: Favicon

Fig.1-10: Exported by a Web Tool

I explored the design of the favicon and eventually came to the conclusion that it should not include text. I found an automatic favicon generator and applied it to my files.
Fig.1-11: Code set in Head tag

Also, for the bottom navigation, I wanted to put the icons and bars in SVG and code to change only the colors, but failed. Therefore, it is implemented in the form of switching over a png image.

Fig.1-12: Lighthouse

Fig.1-13: Score of the Page

When the report was written out in Lighthouse for the completed application, it was not certified for PWA. Therefore, added serviceWorker.js and manifest.json.

Fig.1-14: Edit the Manifest 

The details of the application were defined in here.

Fig.1-15: Offline Operation Supported

Code files and images are pre-loaded for offline operation using this code.

Fig.1-15: Icon setting

Images prepared as favicons are also used as application icons. Some larger sized images are set as "any and maskable".

Fig.1-15: PWA certified

PWA is now certified and can be installed as an app now.

Fig.1-15: Install Option Appeared

Fig.1-15: Installing

After installation on the smartphone is complete, the differences from the browser state are compared below.

Fig.1-15: App Icon

First, the icons have changed to look like native apps.

Fig.1-15: Final Screen in App

In addition, the top bar was changed to the corporate colors defined within the meta tags and manifest.json to complete the look.

P.S.
I forgot to implement the tab feature, I finally added it. (1/12/2023)

Fig.1-16: Purchase Tab

After all, the final outcome, with all pages, functions and settings completed, is shown below.

FINAL OUTCOME

Fig.2-1: Screen Shot of Final Outcome (24/11/2023)

Project Link:

All Data:

Fig.2-2: Video Presentation (24/11/2023)

Fig.2-3: Lighthouse Score and PWA Certification (26/11/2023)

REFLECTIONS

Experiences
Continuing from Application Design 1, we worked on the completion of the designed application, which took a lot of time to complete this time because I had to create more complex pages using not only HTML and CSS but also JavaScript and libraries.　I believe that through this assignment I have roughly understood that HTML is the markup language, whereas CSS is responsible for decoration and JavaScript for behavior. However, even with the same design, a more knowledgeable coder could have written the code in a simpler and smarter way. Even though I completed the visual design, I don't think that all the features could have been implemented efficiently.
    Observation
    In this case, I believe I learned more about the basics of code during the production process. For example, the CSS code used in this project, Display, can be combined with various commands such as block, none, inherit, contents, etc., to give a wide variety of functions to the target. I also learned JavaScript for the first time in this module, which I found revolutionary since I had only been able to create static things with HTML and CSS (although some simple movements, such as blinking, can be implemented with CSS). However, the target of the query, the format for specifying tags, (# and . is necessary or not), and other minor misunderstandings often caused it to stop working. When it affected completely different areas, it was very difficult just to identify what was wrong.

    Findings
    I learned that in the future, when creating websites and applications using HTML, CSS, and JavaScript, we should first think carefully about how to structure them, not just how they look. In this project, there is a part of the project where sections are managed by IDs, but for various reasons, we have no choice but to use classes to manage them. Also, the opening and closing of the modal is managed by gsap animation and JS, but some parts are implemented by adding and deleting classes in JS + CSS. Such inconsistency will probably lead to poor maintainability. Also, a lot of code is managed in one file, which might be easier to split up. I will continue to study to write simpler, more regular, and more effective code.
    Labels:

    Comments

    Post a Comment

    Popular Posts