SIGCHI Conference Paper Format

braintreesmileSoftware and s/w Development

Aug 15, 2012 (4 years and 11 months ago)

279 views


1

MyPiggy


Easy Finance Software

Bey Wang

MS student at Northeastern U.

Boston
, MA
02115

baywang@ccs.neu.edu

Bert Gao

MS student at Northeastern U.

Boston, MA 02115

gaob@ccs.neu.edu

Francisco Crespo

MS student at Northeastern
U.

East Boston, MA 02128

cresp
of@ccs.neu.edu


A
BSTRACT

Quicken and Quick Books are currently the most widely
known pieces of software know
n

to take care of finance. In
a survey of ten people, those who knew of Quick Books or
Quicken did not use it, while the rest simply did not know
of any other program that managed finances
. This paper
presents
the iterative HCI software development, whose
goal is to make

finance
easier to manage and comprehend.

We present this paper in three main sections: Design,
Implementation and Evaluation.
E
ach

section
analyzes

the
contributions user testing had in the interface development.

Author Keywords

Quicken, Quick books
.

ACM Classification Keywords

H5.m. Information interfaces and presentation (e.g., HCI):
Miscellaneous.

I
NTRODUCTION

Finance is a comple
x word and
it does not m
ake sense to
everyone. Targeting on the whole age range, finance
problems might be the common problem that everyone may
face to. Even

if

you do not have a financial problem, then
"How much do you earn? How much did you spend? How
mu
ch do you have now?" They are simple questions, but
not everyone can answer them. We always need money, yet
we rarely can devise a plan to make money. The financial
world is just too complicated. Even if we can generate a
plan, how can we make sure we foll
ow it? Currently, most
financial programs focus on the people who already have
financial problems. Some of them are too large and some of
them are just not user
-
friendly. This has given rise to our
idea of creating a program

that
can help us how to organiz
e,
analyze.

Unless you are an accountant, wall
-
street shark or studied
finance extensively, we could all benefit from a program
that simplifies the financial world for us. So why not have a
program that
helps us

keep

track of our money. Quicken
and Quick B
ooks are currently the most widely known
pieces of software know
n

to take care of finance. In a
survey of ten people, those who knew of Quick Books or
Quicken did not use it, while the rest simply did not know
of any other program that managed finances. Qu
icken and
Quick Books despite being somewhat complicated are
merely tools, not teachers. An easier to use tool would
benefit those who already have some experience in
investment. Adding the teaching component would benefit
the inexperienced younger populat
ion and non
-
experts alike
that would like to see their money grow.

We propose to create software that put
s

the complicated
world of finance into and easily understood and comforting
language that gradually teaches the user. The program
could be able to dis
tinguish users with different financial
background to provide different levels of services. The
application should be equipped with 'learning' intelligence
that can modify the user’s settings as its getting to know the
user. The software will keep as the m
ath stay behind the
screen as much as possible, although allowing users to peek
if they want. Show the users a fun side of spending. Place a
higher attention and smart advices on how

much and
when
to en
joy.

While our ambition was high, this project origina
te
s

from
a
n HCI
course project
. Therefore not only is time
constrained to that of a college semester, but also emphasis
was placed on being able to do iterative design,
implementation and evaluation of our product. Therefore
we had to
concentrate

our atten
tion to three major tasks that
we wished our software to perform:



Creating and managing a budget.



Creating and managing a portfolio.



Monitoring one’s budget and portfolio.

D
ES
CRIPTION

This paper walks through the software development process
used in the cr
eation of myPiggy which can be found at:

http://www.ccs.neu.edu/home/gaob/myPiggy_new.html

Specifically, this paper is broken down into three main
sections: Design, Implementation and Evalu
ation. In each
section we explore the contributions user testing had in the
iterative process of this interface development.

D
ESIGN

The two evaluations conducted in early development stage
contribute to our design decisions and modifications taken
in the d
evelopment of MyPiggy. ‘Paper Prototyping’ is
implemented in the beginning of our design has three
scenarios: User log in MyPiggy creating a new budget,
update personal portfolio, and monitor personal net worth.
Using user observation, we discover the ris
kiest usability

2

problems in MyPiggy are that users have difficulties on
finding the proper buttons to click on while submitting data
in portfolio section. Users also tend to fill out notes and
comments in budget dollar amount fields which will result
in sy
stem errors. We address the issues and make overall
design changes on buttons and displayed messages in
portfolio section. We embed error proof backend coding in
budget interface to filter improper data, automatically
convert conflicting data type to dolla
r format, and easy
-
to
-
understand languages in error messages when necessary.
The details for our paper prototyping can be found in
appendices ‘MyPiggyPaperPrototyping.doc’.

‘Heuristic Evaluation’ is conducted on MyPiggy computer
prototype by 4 users. The f
our users are sampled from
graduate students who are currently taking Human
-
Computer Interaction course. ‘Heuristic Evaluation’
evaluates MyPiggy usability following the heuristic
evaluation procedure from Nielsen's Ten Usability, Nielsen,
J.
Usability Eng
ineering

[2] and usability guidelines from
Human
-
Computer Interaction,

Alan Dix et al [3]. We
carefully examine the results of heuristic evaluations,
appendices ‘MyPiggyHeuristicEval.doc’, from all four
users. We combine and organize the evaluation results

and
implement modifications to MyPiggy interfaces in
improving usability as follows:

1.

Expand budget category tree by default to address the
‘user can not find
the
tree node’ heuristic problem. This
design modification also provide
s

a channel for users
navi
gating not just forward, but backward.

2.

Modify budget category title from step number to
category name.

3.

Add reset button in provide a redo channel.

4.

Add a front panel and reorder the tabbed panel from
‘Monitor’
-

‘Portfolio’
-

‘Budget’ to ‘Main’
-

‘Portfoli
o’


‘Budget’


‘Monitor’ reducing first time user
confusions.


Figure 1a. Default Collapsed Budget Navigation Tree



Figure 1b. Modified Default Expended Budget Tree



Figure 1c. Modified Layout with Added Main Page


The portfolio is designed into thr
ee parts: “Jobs”, “Funds”
and “Properties”

(See Figure 2a)
. These parts are buttons
placed at the top to let the users navigate with ease. These
three parts have the same style, showing a list of records
followed by a few text fields, buttons, and combo bo
xes
used for user input.
This allows users to
choose a record in
the list and change

its contents in the fields below the list
.


3


Figure 2a. Portfolio Layout

The names of the
se

three parts were

initially

“Job’s Pay
Cycle”, “Availab
le Funds” and “Property”

(See Figure 2b)
.
However, after the heuristic evaluation, they were changed
to “Jobs”, “Funds” and “Properties”, because

of the
following observations during:



The “Jobs” page should have more information than just
“Job’s Pay Cycle”



The funds in the “Funds
” page are understood to be
available.



People typically want to keep track of more than one
piece of property.

The three navigation buttons
were designed
to be on
the left
of the page at first. They were moved to the top in order to

keep the layout consist
ent with the r
est of the software (See
Figure 2c). Notice that
the “Budget” and “Monitor” both
have the navigation buttons on the top of the page.



Figure 2b. Initial Portfolio
Navigation



Figure 2c
. Portfolio
Navigation


In the “Jobs” page, there was

a button to show a calendar
for users to choose pay date

(See Figure 2d)
.
After feedback
from the
heuristic evaluation, the calendar

was shown to be
useless and a little confusing. So it was removed after that,
and a combo box was added instead

(See Figur
e 2e)
.



Figure 2d
.
Calendar Alternative


Figure 2e
.
Combo Box Replacement

Another change
occurred in
the “Update” button. It was
named “Update” at first.
D
uring the user test,

at first the
user did not
know it should be used to select
a

record which
was

desired to update.
This button was then
renamed to
“Select” in order to let users know that it should be used to
select
a
record

(See Figure 2f)
. However,
a

second user was
still confused by it; and he still didn’t know it should be
used to update records
.
Noting this confusion by the users,
the “Select” button was
finally removed

(See figure 2g)
.
The c
ontent of the record can
now
be directly showed in the
text fields after clicking on the record in the list.

The list’s
editable function was disabled becau
se
during the user test,
the user first reaction was to attempt to change
the fiel
ds of
the list directly
.

With a fully implemented back end this

4

would be undesirable because we want the user to press the
“Connect” button in order to make any changes.



F
igure 2f
.
Select Button


Figure 2g
.
Select Button Removed

During the us
er test, user

showed little interest in reading

dialog information. Before the user test, the information in
the dialog was complicated

and extensive (See Figure 2h).
After the user te
st, error messages were simplified
to make
them more
noticeable

(See Figure 2i)
.


Figure 2h
.
Error Message Pre
-
User Testing


Figure 2
i
.
Error Message Post
-
User Testing


The Monitor interface
was originally designed to be a line
graph plotting one’s money

as a function of time (See
figure 3a). Performing paper prototyping we saw the flaw in
not having time ranges ready to be viewed by the user and
changed some of the naming conventions such as changing
“Savings” to “Banking”. The heuristic evaluation provi
ded
feedback involving refresh issues and having better error
messages. However when informally asked, users express
ed

agreement in that it would be more useful to see a break
-
down of their finances instead.


Figure 3a. Monitor Initial Prototype

The line
graph idea was dropped, and in its place we now
use a pie chart. The pie chart is designed to give the user an
overall breakdown of their
Budget and Portfolio

finance
.


Figure
3b
. Monitor
before user testing

The pie chart initially did not have percentage
s associated
with the respective labels

(See Figure 3
b)
. The intention
was to avoid
overcrowding the user with information that
may be deemed as unnecessary. The point of the graphical
visualization was to take the user away from staring at
numbers. Howeve
r the users tested seemed to all have an
intuitive understanding that pie charts should have
percentages and expressed concern over this. Consequently,
percentages next to the labels were added to the final

5

version

(See Figure 3c)
. One user, KL, expressed
concern
that they thought the monetary amount on the lower left
hand corner should display the cents as well (Example:
“$10.00” instead of “$10”). After she was explained that
this was purposely done in the case that there were no cents
to expressed, she a
greed with the design.


Figure
3
c
. Monit
or Final Version


I
MPLEMENTATION

MyPiggy is implemented
using

a
Java Applet. The software
has a front page with only one login field aim
ed

to keep
the
interface as simple as possible. We use
a
tree structure in
bud
get
section
to help users navigat
e

through the budget
interface since multiple interfaces are involved in creating
and updating
a
budget. We also provide robust but clear
messages on the top of the interface
to
indicat
e

current
navigati
o
n state

and thus
ke
ep
ing

users informed with their
current state. Data formatting and conversions between
dollar and string data structure
s

were implemented in the
back end of the budget interface to support error detection
and enhance usability.

The goal of the portfolio i
s to record all kinds of user’s
property information. The information is based on the
user’s input, so the rules of
Nielsen’s Heuristics

evaluation
[6] were considered during the design. The implement of
“Table” and “TableModel” were the most complicated
d
uring the design. All the information inputted by users
should be showed in the table and transferred to the
“Portfolio” object. The program also had to update the
contents of the table and adjust the table properties.

The

Monitor feature was implemented u
sing Treanor’s code
[1]. Only those items in budget or portfolio that have some
monetary value greater than zero are displayed. The main
usability issue with a pie chart is the inherent use of color to
display the different sections of the pie. The issue o
f
addressing a color
-
blind audience would have to be dealt
with in future work. But even without this consideration,
implementing the pie chart idea involved the main decision
of which colors to pick to represent each item.

On the one hand there are potent
ially many slices a user
could have for their budget. Yet there are only a limited
number of colors that are considered clearly distinguishable
with one another. For example, a light green colored slice
next to a brown tone of green colored slice would be
less
effective than a plain green colored slice next to say a red
colored slice. While there are 255
3

possible colors in Java
using the RGB value manipulation, this issue was resolved
by limiting the choice of color to the color constants in
Java. This wou
ld mean that some colors would have to be
repeated, but this is a compromise to ensure the ability to
distinguish between slices.

The next issue came in whether we should assign constant
values to each item slice. For example, rent is always red,
food is a
lways blue, internet is always green and so on. This
would seem ideal so that the user (after constant use) could
identify the color quicker than having to read the pie label
or the legend. Since we concluded that there would be color
repetition, we could
avoid having two items with the same
color next to each other. But in the worst case scenario,
suppose that only these two items with the same color
association are to be displayed. This gave rise to the use of
a color table instead. The colors of the item
s to be displayed
would be assigned in the order they are found in the color
table. Therefore, the order of the colors in the color table
would be the same as the order of the colors around the pie.

This solution has the downside that the user could not
a
ssociate an item as always being a certain color. However
in practice, if a user always has the same item in their
budget or portfolio, say rent, water, electricity, food and
internet; then the colors presented could develop said
association, so long as an
y of these items have some
monetary worth.

E
VALUATION

User AL:

Age: 21

Genders: Male


Education: BS student

The first user evaluation was conducted in the computer lab
in

the

Computer Science department of Northeastern
University.
User AL

is a current unde
rgraduate student who
also works in school.
User AL

represents

MyPiggy target
user who has income in starting level, has limited financial
and money management skills
, and

is considering using
computer software in managing money.

We gave
User AL

a brief gr
eeting and simply introductions
on the three primary interfaces that
he

will be testing. We
explain the three tasks: ‘update his existing portfolio’,
‘create a new budget and also update created new budget’,
complete by ‘monitor’ entered information in tes
ting
verbally. We also provide
d

User AL

with task steps in
printed paper format.
User AL

started the test when all
questions were answered prior to the test.
As test

6

conductors
, we

stood

behind
the user

and kep
t

proper
distance while observing
the users in
teraction with the
software. While trying not to
distract

the user we
encourage

the user to conduct the
testing freely and independently.

User AL

had trouble in selecting target item for updating.
He

wa
s confused by the ‘Update’ and ‘Add to List’ button
in

the
Portfolio interface.

The user then tried

clicking
different buttons on
the
screen in order to
submit pay

amount in updating.
User AL

became

frustrated and
sought

help

from
the
test host who provided help by
pointing out
that the
update will take affec
t when the item is ‘highlighted

in

selection mode’.
After he was provided help, the user
could then proceed to the
second task.

User AL

had
little

trouble navigating

through the four steps
divided by budget categories in creating a new budget using
the
nav
igati
o
n tree.
The user could a
lso confirm
ed

and
match up the budget amount with subtotal calculated and
displayed on top screen at the end of each step. Even
though this action is not required, nor mentioned, in our
briefing and test hand out.
AL

encounter
ed an error
message when
he
missed clicking on one check box.
The
user could
examine the error

message and found out the
item

missing in

less than

5 seconds. The rest of the second
task was completed without problems.

When

the u
ser AL

use
d

the
Monitor inte
rface
to
examine
entered portfolio and monitor data displayed in pie chart
graphics,
his initial reaction was to
click on the chart with
the intention to seek more information in display.
The user
simply
exit
ed

Monitor interface after viewing the two
chart
s.

Upon completing the test,
the u
ser AL

volunteer
ed

his
comments and suggestions.
User AL

suggests that the
buttons labeled ‘update’ in portfolio interface should be
eliminated since highlight target update item should
automatically put item in selection.

And the button ‘Add to
List’ in portfolio interface should chang
e to either ‘Update’
or ‘Save’.
User AL

also recommended enhancing the error
proof feature in budget interface since the existing of check
boxes are redundant to budget dollar fields.
User AL

also
thought more
data should be displayed in monitor interface

to allow
users

to

compare

their income versus budget.

User HDC:

Age: 30

Genders: Male


Education: PhD student

When the user HDC tried to login first, he found he has to
click on the “Login” b
utton after typing the password. It’s a
little more complicated than just pressing “Enter” key after
inputting the password. The solution is to add “Keypress”
function to the button. When user was asked to do the first
task of portfolio, he didn’t know how

to change the record.
He first changed the fields of the list directly, and didn’t
know the function of “Select” button. He failed to finish
this task. The problem is catastrophic, and the solution
found to be removing the “Select” button. When user had
s
elected on item in the list by mistake, he didn’t know how
to unselect it. Users were required to press “Reset” button
to unselect one item originally, but that’s not noticeable.
The solution is to add functions to let users click blank
fields to unselect
items. User was also confused by the
“Connect” button when he did the second task in portfolio.
When he was asked to review the instruction again, he
found it should be used to connect bank online. So a
comment should be added near the button in order to m
ake
users know what to do without reading the instructions.

In the “Budget” part, user firstly found the font was too
small and not clear. That’s because the user used a high
resolution monitor, so the font in “Budget” was really tiny.
The solution is to u
se normal font in order to adapt to any
kind of monitor. The user also found he has to check the
checkboxes even if he had filled the text fields, and he had
to save the content in every step.

In the “Monitor” part, after the user reduced the expenses in
t
he “Entertainment” and “Food & Care”, the labels of each
part in the pie chart were crowded, because the amount of
individual expenses was less.

User

KL:

Age: 25

Genders: Female


Education: MS student

User KL was a student at MIT

and a personal friend of a

member of the software team. She is

representative of the
young adult population being targeted.

The test was
conducted by giving her an informal introduction of our
project and reading her the task scenarios as well as giving
her a print out of the tasks

for her reference.
She initially
encountered problems finding the “Jobs” button indicated
in the task scenarios
, mentioning that the Portfolio and task
tabs were “not very noticeable”. Soon after, she noticed a
shameful oversight that the
“Propertis”

butt
on

in the
Portfolio s
hould be spelled “Properties”. She was confused
about how to update the information in portfolio and after
some fooling around she realized to click on the “Select”
button. The “Select” button has since been dropped and all
the user ha
s to do now is to click on the table row they wish
to update.

When
KL

went on to do the Budget task scenario, her first
reaction after re
-
reading the task as “what are the four easy
steps?” Although toiling with the interface allowed her to
guess that the
instructions were referring to “Residence”,
“Utility”, “Food & Care” and “Entertain & Others”; this
brought up the need to modify the tree to include a
respective step number. Immediately after, KL expressed
concern that “Entertain” should be replaced by i
ts noun
version “Entertainment”.

There were two critical incidents when occurred during her
testing of the budget task. The first occurred when KL tried
to change the budget amounts under “Food & Care”. KL
noticed that even though the there was a red mess
age being
displayed saying that the updated amount, the label
displaying the current subtotal did not change. This bug was
persistent through out all the steps except for Residence.

7

The second occurred when the user noticed the
“Note/Description” field. Sh
e commented that if she would
want to leave a note, it should be a text area. When
explained that that field was to specify the “Others”
category, she expressed concern that it should be on the
same line as the “Others” label or replace the label with her
input.

Lastly, when the user moved on to using the Monitor
feature, she pointed out that a “pie chart should have
percentages” and that she was not able to conclude any
percentages just by looking at the slices. As mentioned
earlier, she also expressed con
cern that she
felt

the
monetary amount on the lower left hand corner should
display the cents as well as dollars. However she then
agreed with the design after she was explained that this was
purposely done in the case that there were no cents to
display.

We thanked
each of
our users for their time and expressed
our deepest appreciation for their feedback. We
then briefly
conversed over our thoughts for future modification
s

on
MyPiggy

and

end
ed the test session
.

R
EFLECTION

“The actual design process is ite
rative” is proven during
this project. We reexamine the usability problems collected
through
heuristic evaluation after conducting user tests and
found both the consistence and conflictions between these
two evaluations. There are some problems exposed in
user
testing were earlier identified heuristic evaluation. Even
though our efforts and modifications made after heuristic
evaluation has made similar problems less severe. However
more run of user testing with followed design modifications
are proved to be

a must in order to create a user friendly
system in the end.

“We are not our users” is a motto that was clearly shown
through each one of our three evaluations. In the paper
prototype, we realized that some users tend to keep
everything in one thing and
tend not to divide their finances
into different views as our software suggested. In the
heuristic evaluation, there was much criticism on
implementation aspects such as properly refreshing a
display. This showed us that paper prototyping was more
useful i
n terms of usability feed back. Simple spelling
mistakes would not have been caught had it not been
through some of the comments in the heuristic evaluation
and user testing.

Perhaps, the most useful evaluation had to be the paper
prototyping. Layout usabi
lity flaws were much easier to
modify since the programming was not even started. If
there is something that should be done differently next time
around, it would be being better prepared for the paper
prototyping. This form of evaluation takes some level
of
creativity and is one of those things that one gets better at
with practice.

The User Interface design is hard. The user test is important
during the iterative design. During the test, “
t
he user is
always right” and “the user is not always right”

sayin
gs

were reflected when design
ing

the “Update” button

in the
portfolio
. We trie
d to satisfied different users even though
their comments were
sometimes contradictory
.
In the end,
thanks to user testing, we
chose to remove

buttons deemed
as unnecessary and s
implified our error messages to be
easier to read.

“We are not our users” is a motto that was clearly shown
through each one of our three evaluations. In the paper
prototype, we realized that some users tend to keep
everything in one thing and tend not to
divide their finances
into different views as our software suggested. In the
heuristic evaluation, there was much criticism on
implementation aspects such as properly refreshing a
display. This showed us that paper prototyping was more
useful in terms of u
sability feed bac
k. Simple spelling
mistakes would not have been caught had it not been
through some of the comments in the heuristic evaluation
and user testing.

Perhaps, the most useful evaluation had to be the paper
prototyping. Layout usability flaws w
ere much easier to
modify since the programming was not even started. If
there is something that should be done differently next time
around, it would be being better prepared for the paper
prototyping. This form of evaluation takes some level of
creativit
y and is one of those things that one gets better at
with practice.

F
UTURE
W
ORK

User data is currently saved as objects with no persistence.
A true back
-
end should store
the data in
a

database which is
reliable and
can hold
large amount
s of user data
. The

original design of “Funds” is to be able to connect
to b
anks
and get the personal checking and saving
s information
directly. T
his function
should
be implemented in future
development.

Effort should be placed in handling overcrowding
of

the

pie
chart label
s.

Also, as pointed out by one user’s actions, a
pop
-
up dialog or space on the screen should display more
information when the user clicks on a section of the pie
chart.

C
ONCLUSION

This paper has shown

the

process that was done in the
design, implementati
on and evaluation of a financial
software interface called

M
yPiggy. This software’s sole
intention was to simplify the complex world of finance.

The
main focus of this project was in testing the proposed
software interface using paper prototypes, heuristic

evaluation and user testing. While most of the issues
encountered were resolved for the final version, a few
issues were left
“as
-
is


and
should

be

considered for future
work.
In the end, any
software

interface

is

never truly

8

finalized for there are alway
s improvements that can be
made to better fit the needs

of

our users.

REFERENCES

1.

Treanor, C., and Strader, A. Pie Chart Example.

http://www.coe.tamu.edu/~strader/java/PieCh
art/ver2.1/
PieChart.html

2.

Usability,

Niels
en,

J.

Usability

Engineering

3.

Alan

Dix

et

al.

Human
-
Computer

Interaction


4.

Norman, D.
The Design of Everyday Things

5.

Rosson, M. and Carroll, J. Usability Engineering:
Scenario
-
Based Development of Human
-
Computer
Inter
action. [Ch 2] [Ch 3] [Ch 4] [Ch 5].

6.

Nielsen, J. Usability Engineering [Ch 1][Ch 5] [Ch 6]
[Ch 7]

7.

Fetterman, D. Ethnography: Step by Step [Ch 1 & 3]

8.

Rettig, M. Prototyping for Tiny Fingers.

9.

The Sun Java Swing Tutorial

10.

The Java Look and Feel Design Guidel
ines

11.

Using NetBeans IDE 4.1

12.

GUI Building in NetBeans IDE 4.1

13.

JavaTM 2 Platform, Standard Edition, v 1.3.1 API
Specification
.



9

User Test:

No.

Positive / Negative Feature

Estimated Severity

Solution

“Login”

N

Cannot use “Enter” key instead of pressing t
he
“Login” button.


䵩jor

Add keybo慲d func瑩tnK

“Portfolio”

O

User didn’t know how to change. He firstly changed
the fields directly, and didn’t know the function of
“Select” button.


C慴慳瑲aphe

Remove the “Select” button.
th敮 us敲 捨ooses one 楴imI

瑨e
捯n瑥tt w楬i d楲散瑬y show敤 楮
瑨攠fo汬lwing 瑥t琠t楥汤sK

P

User didn’t know use “Reset” to unselect items.

C慴慳瑲aphe

Add fun捴楯ns 瑯 汥琠us敲s 捬楣i

10

blank fields to unselect items.

4

User was confused by the “Connect” button.

䵡jor

Detail “Con
nect” to “Connect to
Bank Online”

“Budget”

R

䙯n琠楳⁴to sm慬氮

䵩jor

Chang攠瑯 污lg敲 fon琮

S

fnpu琠瑨en s敬散琬twhen us敤 楮pu琠th攠f楥汤I 瑨攠捨散k
box敳⁳eou汤 b攠s敬散瑥tK


䵩jor

Add 瑨攠fun捴楯nK

T

f琠楳 捯mp汩捡瑥l 瑯 s慶攠敶敲y pag攬 shou汤 sa
v攠楮
瑨攠污獴 pag攮

䵩jor

Chang 瑯 s慶攠慴ath攠污獴 pag攮

“Monitor”

U

i慢敬猠慲攠捲ow敤 when th攠amoun琠tf money 楳 汥ssK


䵩jor

Chang攠 th攠 pos楴楯n of 瑨e
污l敬献