Born and raised in San Francisco, I'm a graduate from UCLA, with a Bachelor of Arts in Asian American Studies. During my time there, I took a few computer science courses, which got me interested in developing my front end and back end web development skills - in the hopes of becoming a full stack developer. You can see a few of my projects here on this website! For more information about my skills and personal, feel free to contact me at my personal email: [email protected].
I am not allowed to reveal the client so the artwork has been modified.
I was tasked with developing a website from a concept drawing created by my colleagues at the marketing firm. The goal was to present a website that looks high-end aimed for the seniors and the aging market. The website marketing conceptualized was odd.
I created a wireframe to visualize the website on mobile, tablet and computer. Then after managerial approval, I started to engineer the website. Even though the wireframe was approved, a lot of changes were made to the website as feedback and request changes. It was quite challenging to develop the strange design choices marketing wanted on the website, but I did my best to write dry code for this responsive website compatible with browsers all the way back to Internet Explorer 10.
We had a digital picture frame in our kitchen. Keeping the digital picture frame up-to-date with pictures was a bit of a hassle. We wanted a digital picture frame that can automatically retrieve pictures from the cloud. I also wanted more from the dynamic display that is constantly one.
Android tablets are now really cheap, so I decided to purchase an Amazon Fire tablet. I rooted the tablet and installed the Google Play Store on the tablet followed by Google Photos and Google Chrome. A possible solution was to just view a slideshow from the Google Photos application, but I wanted more from the web connected "digital picture frame." I decided to create my own web application that utilizes the Google Photos/Picasa APIs. I could have created my own Android Application, but it has been 2 years since I have written an Android application, so a web application was easier for me to design and code.
Normal View -> Surveillance Image Expanded
The tablet is simply running Google Chrome and is visiting a special website hosted on my server. Due to cross site scripting limitations, the tablet makes an AJAX request to my server and my server makes the Google Picasa API requests. My server manipulates the data and sends a limited number of picture links and other various data as a JSON to the tablet. Using jQuery, the tablet parses the data and setups the idangero.us Swiper slideshow. The tablet will also make AJAX request for the weather and AJAX request for new frames from the local Blue Iris surveillance server.
My friend, Vong Nguyen, was running for Coast Community College office in Orange County for the November 2016 elections. Vong needed a website to promote his campaign, collect people's contact and collect campaign contributions.
Vong Nguyen has already purchased his own domain and already has a sense of what he wants. Vong wanted a single page site broken down into sections with a sticky navigation bar. I choose Bluehost as our host and Braintree Payments for our payment processing. I choose to use the Bootstrap framework and Adobe TypeKit to utilize contemporary typography. For data storage, I choose to use Google Forms to make it easy for Vong to access and jQuery AJAX to process and send our form data to Google. For server side, I originally wanted to make this a Ruby on Rails application but Bluehost is not the best Rails host. Because of Bluehost and the lack of support for Rails, I choose instead to develop in PHP and utilized the Braintree Payments PHP library installed through Composer.
Body: Futura PT
The UCLA Graduate Student Association's (GSA) website went through a redesign which made it incredibly difficult to find anything due to poor layout and design choices. The subdivision, GSA Publications, wanted to separate themselves from the parent organization's website to gain more control over the content and usability of the website.
The website's goal is usability and long term viability. I recommended a WordPress website because I have prior WordPress experience, is simple and should be easy for future developers to understand. We wanted a theme that was industry standard and choose the Bootstrap framework. To extend WordPress's functionality, we use the Advance Custom Fields plugin to add additional fields to page templates. I also wanted to integrate with UCLA Shibboleth single sign-on, but our system administrators say Shibboleth is not compatible with our server. So instead of Shibboleth, we used Google as our "middle man" for authentication.
Our WordPress website has its own local database and we also connect to the parent's database to pull funding reports. Our solution to a implementing single sign-on is to integrate the WordPress with UCLA Google App Login, which Google authenticates with UCLA's identity and access management services.
We did not add any new taxonomies to the design. Everything can be done with just a Post or a Page.
We have 7 different WordPress page templates in use.
Depending on the template used, different fields exist for different templates with rules defined in the Advance Custom Field plugin. All templates include some special SQL query to show relevant news posts, to show information about parent or child relationships and to present data from other sources - all depending on the template.
In terms of actual design, my director did not want anything too fancy. The website's goal is usability and long term viability. Most of the pages looks like the default Bootstrap example templates.
Pages that differentiate from the Bootstrap example templates are the Front Page and Print Collection pages. The front page needed to communicate news quickly. The Print Collection page looks more like a store front with most recent journals available to purchase through a link.
I wrote the Knowledge Base articles and technical writing.
HumanBlackBox is a native Google Glass application that runs as a background service monitoring the user for a fall or collision. If our algorithm determines the user is in a fall or collision, Glass will record a short video and notify selected contacts that the wearer maybe in trouble.
HumanBlackBox was conceived by me during the 2014 LA Hackathon. At the Hackathon, I unfortunately did not have enough programming knowledge in Java to make the application happen in 72 hours. When I was taking a Java programming class, I introduced this idea to my final project group. Over a month and a half, we researched and developed HumanBlackBox with Katherine Guardado, Byron Icute, Olivia Irving and myself, Logan Cai.
We attempted to patent our code and algorithm with UCLA Office of Intellectual Property & Industry Sponsored Research (OIP) with the assistance of our Professor Blake Hunter. We titled the patent, Automated Video Capture for Wearable Devices, but OIP was unable to secure us a client who will purchase our patent.
Associated Students UCLA had a Microsoft SharePoint server hosting various funding applications for students to apply for funding for their student groups (student groups are like clubs). The SharePoint 2003 server became dated over the years since its creation and was no longer able to handle the volume of applications hitting the server.
We looked at many solutions and determined developing in-house would provide the best and economical solution for our needs. Reasons includes Microsoft discontinuing development for InfoPath forms on SharePoint and our department's operating budget. We developed USAC Funding in a LAMP over 1.5 years.
We have 5 core types of users; students, advisors, funding directors, accounting and system adminstrators.
We wanted to design the web application so any student can submit a funding application on the behalf of their student group. Students are free to make their own personal account or an organizational account if they want to share access other members. But how do we check if the student submitting the application is permitted to submit for that student group? In the back end, we contact the UCLA SOLE database and query who are the signatories. If the person submitting the application is not a signatory, we will still allow the application to be submitted, but the signatories will be notified by email and are allowed to revoke the application. Sometimes the student group will have their own funding directors but are not signatories.
Advisors are assigned by UCLA SOLE. Advisor accounts can be automatically generated or manually generated on a as needed basis with the correct permissions. The advisor is responsible for advising the student groups, making sure they have provided sufficient evidence for their funding request and enforcing the funding rules. Some funding applications does not need the approval of the advisor.
Funding directors and accountants can run reports on the amount requested, approved, denied or pending. Some funding applications goes directly to the funding director bypassing the advisors. Also, some students are also funding directors.
System administrators can intervene at any point of the application process. The application can change any parts of the application when needed.
First, the student submits a funding application. Depending on the funding application rules, an advisor reviews the application or a funding director reviews the application. Then the funding director can prepare the data for hearings and/or allocation and pass the data to accounting. Accounting can audit these funding request. Not pictured; students can then visit usac.ucla.edu to check their available funds. Then the student can submit a General Requisition to access the funds for payment to vendors, purchase order, cash advance etc.
We receive funding applications from students and initially store them locally on our server. The system will contact the appropriate people by querying various databases to review the application and handle supplemental changes and comments made by the reviewer. After a set amount of time, during a CRON job, the server will attempt to move the funding applications to Box as our long term storage solution and free up server storage.
The flowchart is publicly viewable but draw.io requires you, the user, to sign-in with your Google account. But if your organization blocks Google services or if the thing does not load, here's a link to the flow chart.
There was not a lot of traditional actual design work since we were just using the UCLA Gateway template created by UCLA marketing. Most of the design work was just done during front end coding and the occasional paper sketch with colleagues and managers. So instead of creating wireframes, static HTML pages were generated and shared internally because it was a lot easier to work within our predefined design limitations. See the screenshots above for how the site was designed.
In terms of the photos chosen, UCLA LOVES to use pictures of Royce Hall for just about everything. For a previous project on updating usac.ucla.edu website, I choose pictures that related to the undergraduate student government. For this project, I wanted to break away from the traditional Royce Hall pictures and I choose pictures that represents Los Angeles. On the website you will find pictures taken at Little Tokyo, the Hollywood sign but from behind and Downtown Los Angeles. Two of these pictures comes from the creative common. Pictures of Royce Hall unfortunally resurfaces for some pages because that was how the funding director wanted the page to look.
We did do some light UX research. Some of the static HTML and some developmental live pages were shown to close friends, colleagues who are going to be using the web application, select advisors and my manager. In summary, people liked that the website matches the UCLA branding, looks user friendly, was enthusiastic about the automation performed in the back end, ability to add more different funding sources and the improved workflow compared to the previous SharePoint system. Concerns were security of system, ability of system to handle 300+ applications in ~5 minutes and possible unknown bugs.
USAC Funding was launched in the summer of 2015 with first application submitted August 29, 2015. Launch went generally well. There was a bug where approximately 10% of the applications will fail to submit because their student organization's name contained a special character. This issue has been addressed. Other issues were advisors no able to see applications that were assigned to them. It turned out to be a MySQL query issue. As of December 7, 2016, the system has processed over 1,793 funding applications, 4,383 files, 909 student users and $3,183,987.09 of approved funding.