Beacon: Map Sharing and Creation

Beacon is a rails application that allows for simple map creation and sharing. It was created last fall in roughly 5 weeks in a team of four, where I essentially acted as both the technical and design lead. Before the project, the team had attended job fairs and conferences and found several common issues that seemed to plague them, regardless of the sponsor:

• Map given to help navigate the event was hard to process as it would detail every single event/booth over the event's entire duration
• Information overload when information given online - not suited for mobile devices, definitely suited only for desktops
• Lack of context when visiting an event (e.g. information about the company while visiting the booth)
• Hard to access information on a mobile device (maps definitely suited for printing)

Almost everyone has a mobile device now, and it's wasteful to expect everyone to get a printed map or prepare beforehand and print out information needed to attend a job fair successfully. Beacon fills a gap to provide said information easily on a mobile device, while also allowing map sponsors to share and reuse interactive maps online.

Early Steps

Although we could've "faked" the map creation process and focused on the user, I wanted to push myself by leaving my comfort zone and take Rails in a direction I had never gone before. I've made typical web applications with Rails quite often, but never something as interactive as drawing maps. Both in technical and design terms, Beacon presented a new challenge that I wanted to tackle head on.

Some early drafting of the map creation interface

I researched existing "workbench" interfaces, such as Gliffy and Adobe Photoshop. While I used those as references, map creation is different, and required that I also had forms somewhere for the creator to enter information about the "booths" and assign tags that end users would utilize. However, at the same time, certain established patterns (especially for toolbar icons) were used consistently regardless of who made the application, and deviating from such patterns would probably just confuse.

More drafting and planning - went through many iterations in the end!

At the same time, we couldn't ignore the experience of the map users. However, I handed off design of those sections of the application to my team, and devoted myself to the map creation. The tight time span meant that time was spent furiously creating while designing at the same time. It also meant that I had to move forward with a design I wasn't entirely satisfied with, but more on that later.

A color guide I created to help my team use similar colors throughout the application

High fidelity mock up of the map creation page

I planned to have "vendor" and "tag" information all built into it, allowing the creator to deal with all of those pieces in one screen

End Result (~5 wks)

Splash, browsing conventions, and a convention's listing

Could filter the listing by tag, read up on a vendor, and then locate it on the map

Anyone could access the application, regardless if said person had an account or not. They can browse currently ongoing or upcoming conventions, view the "vendors" that are at that convention, read up about them, and then find them on the map. The map itself could be zoomed in and out of, and scrolling/swiping with the finger allowed them to move around.

A fresh new map!

Adding a vendor to the map

You can drag and drop from the circle to assign a vendor to a booth

The map creator can be accessed after creating an account. Many of the interactions are just drag and drop. Drag to create a booth. Drag a vendor's name on top of a booth to assign it. Click on a booth to set the times. You could also toggle vision on each of the vendors or by tag, so that the creator could view which booths had what assigned to it. Another administrative page allowed the creator to finally publish the map, in which it would show up for all users to see.

Now and the Future

One of the biggest challenges was teaching users the "lingo" of Beacon. What's a vendor? How do tags work? Something that would really help is an interactive tutorial or tour of the site that would teach them the basics.

In addition, design of certain components are not ideal. Users didn't know that drag and drop would assign vendors to booths. Some didn't know about shortcuts (control+C to copy paste a booth, for instance). A lot of these issues stem from unintuitive design that doesn't follow existing design patterns or reveal that information outside of long text.

The good news is that I'm continuing to work on this project this semester!

Beacon has been awarded a Carnegie Mellon University SURG grant (student undergraduate research grant), and I now have more time and some funding to continue pushing this project forward for 4 more months. I'm working on redesigning the map creation page and also want to redesign the public convention viewing pages. Other goals are allowing creators to customize their conventions more, whether it be through custom images, drawings, etc. The act of sharing a map also needs to be streamlined, and some users may want to print out a map regardless.

Basically, there are a lot of ways I can go with Beacon, and I'm excited to continue working on it. Check back later and I'll let you know how it's going. : )

Crowdsourcing coffee with expressOH!

Github: https://github.com/angelamuliu/expressOH

Senior year at CMU has been crazy - between balancing senior projects, side jobs, research papers, proposals, and graduate school application, I've barely had time to take a step back and reflect on what's going on! Here's one of many projects made this semester. 

expressOH! is an rails application that crowdsources coffee ordering, made in 2 weeks. You can send an order/request for a nearby store, and then someone in line can pick up that request. Delivery would be in person. Both coffee requesters and deliverers can rate each other. The incentive for deliverers would be a small profit - why not if you're in line already?

Screenshots of the developed application

As most hybrid applications I make, it was designed mobile first and the final product is responsive. Here are some shots of what it looks like when viewed on a larger screen.

The biggest challenge for this application was obviously the time frame. This wasn't a hackathon hack, it was a project for a class that demanded that the product fulfill a need, expected user testing, and solid functionality. There were many features that my team (of three - including me) wanted to add such as live location tracking, texting, venmo, and enhanced user rating. But I'm satisfied with what's there - a flexible database allowing easy entering of new locations, user authentication, responsive UI, clean design, and natural interactions. Many of my classmates expressed interest in a fully fledged application as well. There's a lot of ways I can expand on this project, but that'll have to wait after this semester when I'm not so busy! ; )

I both designed and coded a substantial part of the site (front and backend). Here are some shots of the design process:

Initial sketches! I wanted to have buttons that took up the full mobile width - it turned out looking weird and that got scrapped

Hi-fidelity mockups, and other resources! I think the end product got pretty close.

TartanHacks - TwitterQuizzer

This is a bit delayed, but roughly a month ago I attended a ~1 day Hackathon at Carnegie Mellon called 'TartanHacks" (Feb 6-7). The application my team of three created a simple web app game where people could quiz themselves on how well they knew their friends on twitter. A tweet would be shown to the player and the player then had to guess who it came from.

 

Once the game was over, the player could tweet the score to share.

I was playing as someone else and obviously my score reflects that

My personal goal for this project was presenting a simple interface while experimenting with CSS3 animations. You can't see here, but the heart on the starting screen dips up and down and for each round, the 'card' shows a tweet and flips over to show the answer. This is technically a one page application with parts coming in and out via AJAX, so all transitions also use CSS animations in tandem with javascript. I also got my first real taste of twitter Bootstrap.

In other words, my goal was to create an interface that could easily be understood by anyone, and to accomplish that I went for a simple interface bolstered with animations to make it a seamless experience. Of course there were some issues with this project. Our app interacted with the Twitter API, and we quickly hit the call limit. One way of solving this is creating multiple accounts (each with their own quota). Another issue was that multimedia was returned as a reduced twitter link, and it was difficult to sense what type of media was ultimately returned. An image? A link to soundcloud? A youtube video? In a perfect world, the game would show said media, and we attempted to do this by using a built in twitter embed iframe. But the iframe came with the source user by default, and attempts to obfuscate or remove the name proved frustrating. So for now it simply displays the link.

Regardless, this proved to be a fun and learning experience, and I'm happy with how the application presents itself. Shoutout to Aditi Sarkar and Sangha Lee for being a great team!

Repo link: Coming soon

multiLib - node web app

Last semester felt like sprinting at 400 mph. When break rolled around, it was a sudden halt and I proceeded to catch several(?) mildly awful sicknesses.

Enough of that though, check out multiLib! A web application final project that uses node.js, express, socket.io, mongoDB, and then some. It was created in roughly 1 month for the class 67-328 "Mobile to Cloud."

You can read more about the app and check out the code at its github repo page. It's an online multiplayer mad lib game, hosted on OpenShift at the moment. Although it looks to have multiple pages, multiLib actually is a one page web application that uses socket.io to update what is displayed based on interactions.

Because of the tight timeframe, I choose to focus on 1) making the app responsive and 2) achieving the "minimum viable product." I wanted to ensure the experience was relatively solid and self explanatory. Again, I'd recommend checking out the deployed app to see for yourself (you need 2 people or screens to get the full experience) and judge me on how I did. : )

In case it is taken down though, here are some screenshots:

Robot pictures by yours truly.

Keeping stuff looking good, despite what size it may be!

I would say the biggest challenge was keeping track of all possible events passed with socket.io. Once I got the hang of it, it was pretty simple, but I did end up having 15+ events and 3 different rooms. Another interesting thing for me was using a nosql database (MongoDB). But all and all, making multiLib was a great learning experience and I'm satisfied with what came out.

Hadoop/Spark and RoR Summer Adventures

I worked at the Pittsburgh Supercomputing Center (PSC) over the summer during an internship sponsored by XSEDE. I also juggled helping my 67-272 (Application Design and Development) professor fix/polish an existing Ruby on Rails (RoR) project.

Whew! That's a lot of acronyms. Expect more coming.

PSC XSEDE: A dip into BigData

---

My goal for the internship was to utilize log data about a large webserver named the 'Archiver.' Like most log data, it wasn't being analyzed, just being collected.

This powerpoint I created for my presentation about this project @ the XSEDE'14 Conference summarizes things nicely.

But to go more into detail...I used Hadoop to store cleaned logs. Hadoop allows multiple machines/nodes to act as if it are a single machine, in a sense. I took advantage of the HDFS (Hadoop Distributed File System). Instead of writing a mapReduce function, I ran Spark on top of the Hadoop cluster. Spark allowed me to utilize data inside of the HDFS and conveniently create large in-memory data structures called RDDs (Resilient Distributed Datasets) which I could perform repeated tasks on. Spark also came with a machine learning library module that could be applied onto RDDs.

Data flow @ the PSC for my project

The challenges I bumped into are common for anything 'BigData.' One was getting access to data, and subsequently having to learn my way around the OpenTSDB API (Open Time Series Database). Another was cleaning said log data. I wrote a python script that would query the OpenTSDB, create a CSV, and then place it into the HDFS. I ran this script once a day via crontab. Then there was the problem of incorrectly setup collectors - that had to be amended as well. Of course, bugs were to be expected too.

Collection and cleaning took a substantial chunk of my time. When I had enough data in the HDFS, I moved onto using K-means clustering to examine the data. K-means is a commonly used machine learning algorithm which locates n centoids and matches your datapoints to 'closest' centoids. It allows you to find relationships between dimensions (i.e. filereads vs. CPU) and more! My project's data looked at 5 dimensions about the Archiver: filereads, filewrites, net IO, CPU, and disk IO.

The final step was visualizing the results. For this, I decided to use d3, a javascript library that can visualize documents on the web. The user could change what dimensions he/she wanted to view at a time. Here's what came out of early analysis (shown only on 2 dimensions):

White points are centoids. Colors determine 'area of influence.' If it looks like some centoids have more than others, it's cause other dimensions that aren't being displayed are influencing....

For the last few steps, I was working on making it possible to call the Spark K-means script from the web page and update what was viewed.

My experience at the PSC was overly positive. I got great working experience using Hadoop, Spark, python, d3, javascript, OpenTSDB, and machine learning algorithms. Definitely challenging but greatly rewarding - and I can tell what I've learning will be useful in the years to come.

>> Github repo to most of code

A poster made for XSEDE'14 and Duquesne Presentations. Take a look!

FamilyTyes: A RoR rollercoaster

---

This is a project still in motion. It started at the beginning of summer. A previous (and now separated) team worked to create a web application for the organization, FamilyTyes. This site was to record attendances, keep track of quiz data, and visualize said data. It was to help the organization prove that it had a STEM impact on those enrolled in its classes.

When I came, the site was already very made...in a sense. The backend was quite solid. The frontend, maybe not so much.

BEFORE:

The site as I saw it for the first time. Deployed too

There was a plan to give every student enrolled with FamilyTyes an ID card, and scan said cards to access the system. Cool, but maybe not quickly applicable. So instead, the professor and I decided to make the site mobile friendly (teens have smartphones, right?) and modify the way the whole quizzing process occurred.

That's not good.

Several issues. Current site was not mobile friendly, at all. Also, at some point the site was using Bootstrap, but then switched to foundation. Foundation was not installed as a gem, but rather being loaded in multiple times in many areas. TLDR; this project's views needed a lot of love.

I decided to make the site resemble FamilyTye's home site, otherwise no one would know that the two sites were closely associated. To make it mobile friendly, I created two views - one for mobile, one for web - through the tools foundation provided me. I also have some AJAX here and there to make taking role, etc. faster and more logical.

The new mobile homepage, nav in top left.

You can actually look at the site now @ http://ftdev.info/

Since this is a WIP and for FamilyTyes, I don't want to go any further. At least, until the site is officially released! We want to use the system with kids at the Baldwin High School starting in October. Let's hope that goes well! ; )

cAPP and HCI

I got into CMU's undergraduate HCI double major program! This happened awhile ago, sorry for the late update.

In the meantime, enjoy this bit of work I did is for an entrepreneurship class midterm group project (what a mouthful). What we came up with was 'cAPP,' a fit-all drug cap that would sense when the bottle was opened and sync with a smart phone application which keeps track of your medical schedule. Here are some of the rough mocks I did for the presentation that illustrate its function.

Sophomore year is nearly over. Just one more week of finals / projects, and I'll be done! Expect to see more work posted here once that happens.

On a tangent, I'll be working in Pittsburgh this summer. I've gotten a research opportunity at Pittsburgh Super Computing (PSC) and hopefully, will also be able to help a professor with some research. Looking forward to a productive break until junior year...