We will synthesize the knowledge gained in
tasks 1, 2, and 3 for application in this final
project. We will create an integrated visual
asset and refine the prototype into a complete
working and functional product experience for 1
task flow.
The task flow is: Lockscreen > Login > Home
> Notification > New Transfer > Select
Cathy > > Enter amount > Check details
> Enter password > Success
Fig 1.1. Task Flow Screens
A. Combining Prototype
The screens I have completed in Dreamweaver
are:
Loading
Lockscreen
Login
Home
Notifications (mail, news,
promotions)
Side Navigation Menu
Transfer
Select bank
I began by consolidating the files into a single
project, as I had worked with multiple files in
Task 3. This step required me to reorganize
various elements, such as headers, images, and
paragraphs, to ensure everything was categorized
correctly. During this process, I encountered some
issues with the positioning of containers and
text, as their position was set to relative. As a
result, certain elements would appear out of
place. I had to go through and carefully adjust
their positions to ensure everything aligned
properly and looked as intended.
B. Password Handling According to the task flow, users are required to
enter a passcode after reviewing the details. To
achieve this, I planned to implement a passcode
handling system that allows users to click on
random 6-digit numbers, with each digit filling in
a round one by one.
I began by focusing
on the user interface (UI) first, which was
relatively straightforward since it followed a
similar structure to the other pages within this
section. This made the process of setting up the
basic layout and ensuring consistency across the
design easier.
Fig 3.1. Password UI
Then I added a active status of the button,
which is changing the background to
#C3C3C3. Once the UI was in place, I moved on to
handling the functionality behind the passcode
system, allowing the user interactions to
trigger the filling of the digits in the
designated rounds.
Fig 3.2. Password Handling
The script first selects all elements with the
class .round (the places where numbers are
entered) and .number_first, .number_second,
.number_third, and .number_last (the buttons for
the digits). It initializes an empty string
enteredNumbers to store the user's input. When
any of the number buttons is clicked, it checks
if the length of the entered numbers is less
than the number of rounds (spaces for digits).
If so, the number clicked is added to the
enteredNumbers string, and the corresponding
round element is marked as "filled" by adding a
class. The button is briefly highlighted using
the "active" class, which is removed after a
short delay.
Once all rounds are filled (when the entered
numbers' length matches the rounds' length), a
timeline animation is triggered using the GSAP.
The animation smoothly transitions pageFour out
of view and brings pageFive into view. The use
of setTimeout ensures that the button's active
state is temporary, providing a visual effect
that helps users know their input was
registered.
Then I tried to make the delete button function.
I added an ID to the delete button and select it
in the script using get element by ID.
Fig 3.3. Delete Button Function
This code snippet manages the behavior of a
delete button that allows users to remove the
last entered digit from their passcode input.
When the delete button is clicked, the function
first checks if the enteredNumbers string is not
empty, indicating that the user has entered at
least one digit. If so, it calculates the index
of the last entered number by subtracting one
from the string length. The code then updates
the enteredNumbers string by slicing off the
last character. Additionally, it removes the
"filled" class from the corresponding round
element in the UI, visually reflecting the
deletion by clearing the input field. This
ensures that both the internal data and the
visual display are synchronized when a digit is
deleted.
Fig 4.1. shows the interface design of this
section using Dreamweaver.
Fig 4.1. Confirmation Message UI
Once users enter the correct password, the
system will automatically transition to display
a confirmation message. This process happens
seamlessly, without requiring any additional
input from the user. As soon as the password is
validated, the interface quickly updates to show
the confirmation, signaling that the user's
input was successful. This smooth transition
ensures a user-friendly experience, where the
system responds promptly and efficiently,
minimizing any delays or interruptions in the
flow.
After the confirmation message appears, users are
presented with the option to either download the
receipt or return to the home screen. If they
choose to download the receipt, they can easily
click on the download button, allowing them to
save a digital copy of the transaction for their
records. Alternatively, if they wish to return to
the home screen, they can press the "OK" button.
This section will fades out and the home screen
will fades in. The design offers flexibility,
allowing users to decide how they want to proceed
based on their needs.
The switch-case statement in JavaScript is a
control structure that allows evaluating a
variable against multiple possible values,
making it easier to choose one out of several
actions based on that variable's value. It is
an alternative to using multiple if-else
statements when there were several conditions
that depend on the value of a single variable.
The switch statement checks the value of a
given expression, and for each possible value,
there is a case. When the variable matches a
specific case, the code block under that case
is executed. If none of the cases match, the
default case can be used to handle any
unmatched values.
In the switch-case structure, each case
represents a specific condition. Once a case
matches, the corresponding block of code runs.
The break statement is important because it
stops the code from running into the next
case. Without break, the code would continue
running through the following cases until a
break is encountered, which is not what I
want. This is called "falling through" and is
typically avoided unless intentional.
For example, in the provided code, the
switch-case is used to check the value of
currentPage. Depending on which page is
currently active, the code performs different
animations or actions, like moving between
pages or changing the opacity. This helps keep
the code clean and organized, especially when
you need to handle several possible scenarios.
Using a switch-case statement simplifies the
process of checking for multiple conditions
and ensures that the correct actions are taken
based on the value of a single variable.
Lastly for page four and five, I made the back
button non-visible following the Figma.
Finally, I upload the file to Netlify, and here
are some issues of running the app:
1. Sometimes the UI will go weird suddenly and
the animation will not run or glitch, you just
need to refresh the link or reopen it.
2. The app’s dimensions are fixed at 340x750
to address the significant impact of using the
same percentage-based layout across different
screen sizes. When I set percentages for
positioning elements, it works well in the default
dimension, but issues arise on other
devices.
For example, when I set the header to left: 20%,
it appears correctly positioned on the standard
layout. However, on my iPhone 13, it shifts too
far to the right. This discrepancy occurs because
the percentage-based positioning is calculated
relative to the screen size, and different devices
have varying screen dimensions and
resolutions.
I initially tried using align-content and
justify-content to resolve the layout issues, but
these approaches didn't provide the desired
results. As a result, the fixed dimensions ensure
consistent alignment and scaling. I also
experimented with an iframe, hoping it would solve
the issue of screen size discrepancies.
Unfortunately, this approach didn’t work as
expected. When using the iframe, the login
container didn’t fully slide up as intended. The
positioning and transition animations were
disrupted, preventing the container from reaching
the correct height and properly displaying the
login elements. It seems the iframe caused
conflicts with the layout behavior, especially
with dynamic elements like the sliding container,
which made me have to make the decision to fix the
dimensions in order to resolve the screen size and
layout inconsistencies across different
devices.
Working on the project was quite a
challenge for me, especially when I faced
issues with adaptability. At the
beginning, I had a vision of how I wanted
everything to work, but as I started
implementing it, things didn’t turn out as
I imagined. This made me feel really sad
and frustrated because it wasn’t as
perfect as I had hoped. The idea of making
everything seamless and flawless didn’t
quite match the reality of facing these
obstacles, which made the experience
harder than expected.
One of the most difficult parts of this
process was dealing with new problems that
kept popping up. It felt like every time I
fixed one issue, another one would appear,
and it seemed like I was going in circles.
These problems took a lot of time to
solve, sometimes taking hours. However, I
learned that this was part of the process,
and it taught me how to be more patient
and persistent.
Despite the setbacks, I’m glad I had the
opportunity to work through these
challenges. Solving the problems, even if
it took longer than I had hoped, helped me
become more resourceful. I started to
think more critically about the problems
and explore different solutions. Even
though it didn’t turn out perfectly, I
gained valuable experience and learned a
lot about myself as a problem-solver. It
showed me that not everything needs to be
perfect, as long as I keep trying and
learning along the way.
Comments
Post a Comment