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. : )

Ecocarnival Alpha

In an early class I took for my undergraduate degree in Information Systems, a team and I came up with the concept "Ecocarnival." It was pitched as a collection of mobile games that taught its players about green practices.

The old posts: [1] [2]

Fast forward to now, four years later, I implemented the application via xCode 7, Swift 2, Spritekit, Core Animation, and Core Graphics for 67422, a class about iOS development. It ended up winning best of class, netting me an iPad air! Here's a video of me playing on an emulator though.

While Ecocarnival is supposed to be a collection of games, it actually only has one at the moment. The one you see above in the video and screenshots is "Trash Ninja," which is inspired by Halfbrick Studios "Fruit Ninja." But there are a lot of twists that differentiate the two games.

In "Trash Ninja," you have to sort trash into the right bin. See a chocolate bar? Toss it in the trash. A soda can? That goes in recycling. A rat? That...goes on the ground. Don't put the rat in the trash. Making the wrong move causes you to lose a life. As you earn points by making the right decisions, the game is paused and a new item is added to the pool. This way, people will steadily learn what is recyclable and what is not.

The start screen acts as a portal to other games

While the game is simple from the user's perspective, there are actually a lot of small things happening in the background. Items have different percentages of spawning (40% trash, 40% recyclable, 15% animals, 5% power ups) and within each category, my game picks out something to spawn given the pool of available items. Point values are based on how common the item is.

In game! Using Spritekit to simulate physics. Can touch the drag trash and toss it into the right bin

Meanwhile, items (really subclasses of SKSpriteNodes) can detect collision and, essentially, when they collide with a trash can. That's when I detect if a right decision has been made. The pause screen is actually a UIView that pauses the scene and presents itself over it - allowing players to dismiss it and return to the game without being taken to "somewhere else."

Game over with the custom UIview, when a new high score is made. I liked implementing the confetti 

Programming for iOS presents its own unique challenges. I feel I learned a lot about how to keep a xCode project optimized and organized in their way (using groups instead of folders, a spriteatlas, etc). I learned how to properly debug Swift, how to search for memory leaks, how to install modules via Cocoapods, managing app state, saving data, and more. One thing I'd like to continue improving on is implementing responsive layouts however. Autolayout didn't really work for many of my more complex screens, and I'd like to research what the best way to achieve responsiveness is for native applications.

Still, I think it's really fitting to close off this year by creating a project that, four years ago, I thought I'd never be able to do! I feel that Ecocarnival can be built on in the future as well (adding a compost bin to Trash ninja, other games, a leaderboard, fixing and polishing, currency... so many possibilities!) so who knows? Perhaps you'll see it in the app store one day.  : )

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.

Salesforce - Hit the Ground Running

This summer I interned at Salesforce, where I worked as a fullstack developer, specifically on the service cloud. Here are my key takeaways:

1. Legacy code is a thing

1. Good documentation is a blessing and tremendously helps speed up the process.
2. If you got tools, use them. (Using an IDE? Take advantage of its features!)
3. Find people, and talk!

Here's the catch: often code is orphaned and does not have an owner. It just happens - People leave the company, one file has multiple owners, a file has too general a purpose, etc. I'm glad I got to learn from doing and definitely, there's a difference between me before and me after the internship.

2. Browser compatibility is a thing

Usually, it's an old version of IE restricting what you can and cannot do. Got a fancy HTML5 feature you learned in class that you want to use? Think twice - can it be supported? Same goes for CSS and Javascript. Working at Salesforce provided a good challenge as I had to find ways to solve a complex issue with a solution that would work in all sorts of settings. You can't just ignore the 5 or so percent of users still on fossilized browsers because that translates to a whole lot of people!

3. Accessibility is a thing

Accessibility, along with browser compatibility, are topics tossed around in school but few classes actually teach. But it's something that exists, and something all developers and designers should keep in mind. How can code solve this problem? How can design solve this problem? How does one evaluate design? And actually, how can applications and future interfaces (whether on web, a touch device, or whatever the future holds) be built to be more accessible? Just like how some users use IE, some users have accessibility issues that we, as developers, can address.

4. Code debt is a thing

Unfortunately, the real world isn't like school where you can hack together a project, turn it in, and then turn over a new leaf and start anew. Everything I write must be understandable because it could be reused, reworked, or cleaned out in the future. One part of this is not having a huge magical do-everything method. Another is following existing naming convention. But also not using impressive but totally unreadable one-liners is also a thing. Leaving good comments and having simple, easy to follow code means someone in the future will be happy. I know the pain.

5. Agile development is an awesome thing!

Probably the most useful thing of it though is giving people ownership of what they're doing. Announcing it every day makes you commit to tasks. But it also lets others know what you've been toying with. I may be working with "this side" of the code mostly, but that doesn't mean I'm not interested in others! What I learn today can help greatly for future possible stories - and it helps foster a more collaborative team.

6. Specialized roles are a thing

School has trained me to take on an ace-of-all-spades sort of role just because projects are occasionally solo. This portfolio/blog is a testament to that - design, art, programming all mixed in. But often we work in teams, and members have roles. The focus then shifts to fostering good relationships with team members and communication  - but the benefits are great! For one, you're not lonely. But next, they often share a fresh point of view that helps make a better product and experience. Even I got wrapped up into "technical" stuff after working with code for so long - but a talk with the team writer helped me take a step back and look at what I created. A good team makes you think critically and not just churn out work. 

7. Taking care of yourself is a thing

Coming in with a good night's rest made a huge difference for productivity. Not having my shoulders hurt from sitting also helps. And eating well too! Sometimes you get sucked into work, but having a life outside of it actually impacts productivity! When I talk with coworkers, I don't always want to talk work because sometimes all we need is a bit of time to relax and loosen our brains a bit. I don't think all nighters, ramen dinners, and the stereotypical "college lifestyle" is something that should be sustained, especially once you're working.

I could go on, but then this immense text block would be truly terrifying. I had a great time at Salesforce because my team was very welcoming and friendly. But also because the Salesforce internship program is well run! There were challenges that I was able to overcome, and I think I've both grown as a developer and as a person as a result. I would highly recommend the company! Mahalo for making my summer awesome!

Tldr: Read the bolds and my team at Salesforce was awesome!

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

GGJ - A Platforming Postmortem

This weekend was the Global Game Jam, where gamedevs and game enthusiasts (me) craft games within 48 hours. I entered my first game jam excited to make games that I'd love playing. I knew there was a steep learning curve for me - I had never used Unity and also never programmed in C#. Luckily, it wasn't hard to pick up even in the tight time constraints, and I prepared beforehand.

So what did my team make? We created a simple geometric 2D platforming game using the Unity2D engine. You - a triangle - must fling yourself across shape themed terrain and find a home - whether it be in a square, a pentagon, or in another cluster of triangles. There's also the mechanic of 'changing yourself' to fit in with different shapes. As you change, you also exchange abilities (jump height, wall jump, speed).

Game name: Full Circle

Github repo: https://github.com/angelamuliu/squaretown

GGJ Link: http://globalgamejam.org/2015/games/full-circle

That's what came out - but what did I do? Although I could have worked on the UI or art easily, I wanted to challenge myself. I was one of two programmers on the project. Fortunately for me, C# is similar to Java so I had no issues writing in it. The biggest challenge was working in the framework of Unity, and of course others issues like how should we move the player? Should we use physics or allow greater control by building it from the ground up (we did a mix of the two)? Other programming challenges I solved was ground checking for the triangle, state switching and activating objects, creating crumbling platforms, and well...there were just a plethora of scripts that had to be done.

Using a triangle as the player led to fun challenges and insane jump spins!

What were the biggest challenges? I suppose learning Unity while furiously trying to also make progress was one, but I find myself in that situation a lot (learning on the fly) so actually, it was kind of fun and very rewarding. I took charge with source control (Git) since my teammates were less experienced in the area, and found myself fix the ever common issue of 'someone overwrote my change what do I do please help' situations that came up. 

But by far, the biggest challenge was team coordination. My teammates were awesome and talented people, and great to talk with outside the context of a game creating marathon. But there was quite a bit of friction when it came down to making tough decisions and doing work. Sometimes one person wouldn't agree no matter what, so we had to adapt. This occasionally involved scrapping a lot of good work to get a person on board...which in turn, turned off other teammates. I had to make a lot of creative sacrifices for the sake of bringing the team together, which is okay. But next time I'd like to make something that goes beyond conventional gaming practices - this was a game jam after all!

But overall, I believe it was a great experience. I feel more confident working with Unity, C#, Git, and more after just two days working with said tools. And I learned a lot about working in teams. Now that I've got the basics down, I can make something really special in my own time.

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.