Penn Labs RSS Feed

Penn Clubs: Shooting Yourself in the Foot with Kubernetes

Thu, 18 Sep 2025 00:00:00 GMT

Penn Clubs: Shooting Yourself in the Foot with Kubernetes

Every semester, hundreds of Penn students apply to dozens of Wharton Council clubs through Penn Clubs, a product of Penn Labs. It might look like a simple web app — a few forms, a few clicks — but behind the scenes, Penn Clubs must withstand one of the most intense and predictable traffic surges on campus.

Here’s how we prepare for it, what went wrong this fall, and the lessons we took away to make the platform even stronger.

The Problem: Midnight Traffic Surges

For Wharton Council–affiliated organizations, the application process has a unique constraint:

There are 68 clubs on the Wharton Council, and
All must set their application deadline for the same time — midnight.

This creates a perfect storm:

Roughly 1,300 students submit applications in the one-hour window before midnight
That means about 10,000 application response objects are written to the database in that single hour

It’s our most intense load of the semester — and if anything fails, students lose their shot at joining clubs. With the anticipation of peak load, we take the preparations necessary to ensure the platform is ready for the surge.

Our Solution: Preparing for the Surge

Over the years, we’ve made several improvements to ensure Penn Clubs stays fast and reliable during the crunch:

Backend Query Optimization

We profiled and optimized our Django queries, adding missing indexes, eliminating redundant writes, and restructuring slow filters to make application submissions lightning-fast.

Aggressive Read Caching

Many students refresh the site repeatedly to confirm their submissions. We cache common reads aggressively to prevent the database from getting overwhelmed, while still keeping data fresh.

Preemptive Horizontal Scaling on EKS

Before the deadline, we scale up our EC2 instances running on EKS (Elastic Kubernetes Service) — using non-spot instances to avoid sudden preemption — so we can handle thousands of concurrent requests with headroom to spare.

This has allowed us to handle years of midnight surges with zero downtime. But in Fall 2025, we made a critical (false positive) mistake.

The War Room

The Penn Labs War Room is a tradition every semester. The team gathers — usually in a GSR — dashboards up, snacks in hand, ready to make sure Penn Clubs survives its biggest night.

This semester, that watch party turned into a real firefight.

9:00 PM — War Room Goes Live As usual, the Clubs & Platform team spins up monitoring dashboards and keeps an eye on alerts. This hour is usually calm — but not tonight.

10:00 PM — Something Feels Off

“We have 800 database connections already — why?” This was completely abnormal for 10 PM. CPU, memory, and disk I/O were perfectly healthy — no blocking queries, no I/O saturation — just a wall of open database connections.

10:20 PM — First Attempts We debate scaling up the RDS instance, but that would require a restart, and the midnight deadline is too close. Setting up an RDS Proxy isn’t viable either — it would take too long. We hold steady, but keep digging.

10:50 PM — The Plot Twist Someone scrolls back through historical metrics.

“Wait — this started at 5:30 PM, exactly when we scaled up our deployments.” The room goes quiet. This wasn’t user load. This was us.

11:00 PM — The Puzzle Snaps Together Julian, Clubs lead, joins and adds the missing piece:

“We also increased the number of worker threads this semester.” The realization hits:

tripled deployments × more workers per deployment = triple the database connections.

We hadn’t been attacked — we’d accidentally DDoS’d our own database.

11:05 PM — The Fix We scale down our deployments. Instantly, the database connection graph drops like a rock. The War Room erupts in cheers. The database is healthy, the platform is stable, and we go into the busiest hour of the semester with confidence.

By 12:00 AM, the deadline passes without a single outage. Another successful application season — and a hard-earned lesson for the team.

We survived the application season with the smallest RDS instance in history, with just 8GB of RAM.

Key Takeaway: Scaling is Holistic

This experience taught us that:

Scaling horizontally isn’t just about adding more servers — you must scale your database alongside them, or you risk creating the bottleneck yourself.

Connection pooling, database capacity, and worker counts all need to be considered together. Otherwise, you can overwhelm your own infrastructure before the first user request even hits.

The Future: Message Queues for Even More Reliability

For a long time, I've had some thoughts about the next chapter of Penn Clubs: adding message queues(like Amazon SQS, Kafka, or RabbitMQ) to the Club application pipeline to improve reliability and reduce EC2 costs.

Instead of writing directly to the database during peak load, we could:

Enqueue submissions and immediately acknowledge them to users
Process them asynchronously, smoothing out traffic spikes
Scale background workers independently of the web layer
Allow delayed database writes to spread out over time

This will improve reliability, reduce EC2 costs, and give us better observability into throughput and retries. We're hoping this will help us avoid a similar situation in the future.

Final Thoughts

Penn Clubs isn’t just a website — it’s a platform that has to perform perfectly during one of the most stressful hours of the semester. The Fall 2025 War Room reminded us why we watch so closely: scaling isn’t about “more” — it’s about scaling "everything" together.

With continued improvements — smarter connection pooling, better autoscaling, and message queues — we’ll keep making Penn Clubs a platform students can count on, even at 11:59 PM on deadline night.

As a final remark, I want to thank the Clubs & Platform team for their hard work and dedication to making Penn Clubs a success. I'm proud to be a part of this team and I'm looking forward to seeing what we can accomplish together in the future!

For Students, By Students: The Role of Penn Labs in the Penn Experience

Sun, 07 Sep 2025 00:00:00 GMT

Last week, I pitched Penn Labs to students at the annual SAC Fair, our informational sessions, and other recruiting events. Like other student organizations, these events are crucial touchpoints for prospective members. Though, I noticed that my conversations often started with:

Me: Are you interested in joining Penn Labs?

Random Freshman: What's that?

Me: Have you used Penn Course Review, Penn Course Plan, Penn Mobile, Office Hours Queue, or Penn Clubs?

Random Freshman: Yes....

Me: Those are all Penn Labs products!

Random Freshman: WOAHHH!! THAT'S REALLY COOL!

Me: [insert overrehearsed sales pitch here]

It's at this point that I realized that Penn Labs is unique in that people learn about our work before they learn about our club. This is a realization that was two years in the making and underlies some key things that I've learned about my time at Penn Labs.

1. Product direction is a function of the user and their experiences

I joined Penn Labs in Spring 2024 as a member of the iOS team. This gave me the opportunity to work on Penn Mobile. After onboarding and completing an introductory project, I remember struggling to find something to work on. My team leads at the time, Jordan and Anthony, looked at me (after my intro project crashed Penn Mobile and they had fixed it) and essentially said:

Anthony and Jordan: Don't worry about it, that's normal. Just find something that you don't like and make it better.

By giving me a lot of latitude in deciding what to work on, my lens of product direction shifted from that of a prospective software engineer to that of a user. Furthermore, this opened my eyes to the motive behind Penn Labs' products at large: find something that people find difficult and make it easier.

Product direction has always been a challenge for me. It's a tough call deciding what things to tackle first, what problems are worth solving, what ideas are worth acting upon. However, my time in Penn Labs has taught me that it's all about the user. Building cool products is fun, exciting, and impactful largely because there's someone on the other side whose life is made better by them.

As an iOS developer, it feels right to quote Steve Jobs on this one:

"You've got to start with the customer experience and work backward to the technology."

- Steve Jobs, WWDC 1997

So how do we decide what to work on? Simply put, we put our Penn student caps back on and think about the challenges we face. For one, degree planning is consistently a challenge here at Penn. We're working on it (I promise). But it's those types of challenges that stand out as unbelievable product ideas; the allure of solving a problem that just one student faces is all too common among our talented team members.

2. Writing code isn't the entire picture

After spending a year on the iOS team, I moved up to the role of iOS team lead. I was still developing Penn Mobile, but I was interacting with many more product teams at a much deeper level. It's here where I realized that these interactions are the not-so-apparent responsibility of a team lead. Simply put, interacting with product teams, students, and other stakeholders is just as much a part of the role as is writing the code, leading your team, and solving the problem.

Penn Labs is so much more than a team of software engineers. We have members whose talents are in infrastructure management (which is largely software, but also operations/cost analysis), user interface design, social media marketing, and product management. To remain in one's bubble—that is, to focus only on the software—goes against everything we do well as an organization. There's a reason that our products are discovered before our club: the efforts needed to make that product effective, easy-to-use, and well-marketed took genuine talent that is largely the result of the interaction between these different teams (and the skills of those teams themselves). Penn Labs is a melting pot of perspectives, backgrounds, and experiences so far beyond, and including, the Penn sphere.

Another overlooked part of the job is the relationships. We have worked tirelessly to maintain relationships with our various stakeholders: advisory boards, Penn administrators, Penn IT, and foremost: Penn students. While writing code is paramount to show potential value, being able to speak about impact and results to those who support your work is also fundamental to the work we do and the effect we have on the Penn experience.

Writing code is not the entire picture. In fact, it's naïve to look at our organization as a group of software engineers. The products we build are a result of inter-team conversations and debates, the cultivation of productive relationships with stakeholders, and genuine talent and care by the students who volunteer to make these products for the Penn community.

Conclusion

I'm going into my stint as the co-director of Penn Labs for the next year. I'm excited further this direction and mindset, and I'm also excited to bring on new members who align with this. With that, our application is open on Penn Clubs (which is cool since it's our product). So if anything I wrote here resonates with you, apply.

My experience at Penn Labs has been enlightening. It's been a ton of fun learning from the talented members around me who are excited to show me how cool the work they're doing actually is.

As I said, we work hard to cultivate a relationship with Penn students and other stakeholders. If you have comments about our work or ideas, reach out to us at contact@pennlabs.org.

False Promises and Related Rabbitholes

Thu, 12 Jan 2023 00:00:00 GMT

The 19th of September, 2022 might have been an innocuous Monday for most, but over at Penn Clubs -- things were getting rocky. The last day of the Wharton Council Centralised Application, Penn Clubs went down for around 10 minutes in the afternoon. We quickly pinpointed database throttling as the cause, bumped up our instance class and things were golden again -- no other telltale issues.

Fairly normal, we thought. It's the last day of applications. Of course everyone was getting their submissions in last minute. With fairly substantial historical load (~1500 unique applicants, ~5000 applications), we brushed it off as a "random" failure of the database. Everything else was green too; the usual pod, CPU, memory, node metrics looked great so I was confident that nothing worse could happen.

My affirmation to the Wharton Council representative.

Famous last words.

I was sipping on some whisky and watching TV with some friends at around 9pm when I received the unfortunate news that Penn Clubs was down, again. Looked like the Targaryen family feuds had to wait! Uptime was more pressing.

Problem

After about 30 minutes of staring at metrics dashboards, the platform team, outgoing co-director Campbell, and I eventually pinpointed that it was the database (and only the database) again. Somehow we were at 99.9% CPU utilization, which effectively throttled read/write performance severely. We figured there was an excess of queries running which not only slowed query speeds to a crawl but also, strangely, left behind some long-running "suspended" queries that were busy-waiting on the database CPU.

Busy-waiting is a computer science concept which involves a stalling process being scheduled by a system (OS, database, etc) -- resulting in using 100% of available CPU. The simplest example of a busy wait is as follows:

int main(void) {
	printf("Loop forever\n");
	while (1) {
	}
}

In this case, the long running queries were frozen but the database didn't know any better to terminate them, so they hogged the majority of the CPU. Our immediate hotfix, kudos to Campbell, was to write a script that periodically killed all long-running queries (>30s runtime).

However, perhaps more importantly, it didn't quite make sense to us why we had so many queries hitting the database, and even less so why some were magically frozen. Our database instance class was not small and our load should have been ~O(1000) qps, perfectly reasonable given our infrastructure setup. And so we jumped down the investigative rabbithole!

Profiling Penn Clubs

Penn Clubs is probably one of our more involved products in terms of database design. We employ a variety of models to capture the nuances of user, clubs, fairs, applications and their relations. Crucially, as we scale, this introduces a lot of scope for complex queries, elaborate Python logic, and Django ORM inefficiencies -- all of which could trickle down to various database problems.

Queries, Queries, and more Queries

To dig at the root of this problem, we started with looking at which API endpoints took the longest to respond (thanks to Peyton). To do this, we used a piece of software called Datadog, which hooks into all our products and collects important monitoring data.

Wow! Looks like /api/clubs (the homepage) could be really slow. This makes sense, since the list of clubs we load on the homepage involved a lot of SQL joins, ordering, and computing aggregations. Importantly, for someone to get to the application page, they were likely visiting the homepage first, then going to individual clubs' homepages, and finally clicking the Apply button. In the process, we ran this expensive and ugly query for /api/clubs , as well as one for /api/clubs/<club_code> .

This clearly created a lot of redundancy: each user that wanted to apply to a club would inadvertently trigger a set of expensive database operations that were unnecessary - the list of clubs and their related fields are mostly static. Queries to these pages, while optimised, were still large and operated on about ~100k DB objects across tables.

To solve this, we introduced a cache layer to our core backend services. This cached the database-computed queryset with a TTL of 1 hour. We invalidated this cache on object creation or updates (as well as updates to important related fields). During peak traffic, this was sure to minimize load on the database and maintain the performance of our website. Reads from Redis are very fast (we averaged 4.2ms using the Django cache client), so we expected our API to get faster too.

Optimisation, ft. the N+1 problem

Another pain point in our code was that we had some of our more complex query logic written in Python (using for loops and Python objects). Python is notoriously slow at CPU intensive tasks, but at the same time the query was not expressable using the usual set of Django ORM functions. We had to insert some Raw SQL to transfer the heavy lifting over to the database. While this is generally frowned upon, it is useful in cases where the ORM fails to model the desired query exactly. This improved query performance for the same set of objects by around ~10x.

We were also a victim of the infamous N+1 problem. Many of our serializer calls also invoked related fields' serializers which slipped through our notice but added on extra queries. The presence of multiple many-to-many relationships meant that fixing these queries (using Django's Prefetch and select_related led to a reduction in the number of queries hitting the database (per lookup of affected objects) by a factor of ~100!

A common theme with these two problems is that they are both rooted in the pitfalls of the Django ORM. While the ORM is certainly convenient, readable, and intuitive to use, it requires some degree of expertise to write performant code with. It's certainly better than writing only SQL though. We're not a data science club.

Caching redux

At this point, we've implemented a fairly robust cache layer and also optimised our database logic so our endpoints do at most 5-6 queries on the DB. However, performance wasn't quite where we wanted it to be. For some reason, some of the heavier endpoints still took >3 seconds. Our database isn't that large, so this was puzzling. Additionally, our stack (React + Django) was not chosen for blazingly fast performance, but we were still slower than expected.

Digging even further, the problem seemed to lie in the serializer. For the application submission route (optimised earlier using raw SQL), the query by itself took less than a second, but serializing took around ~7s. It is apparently well known that model serializers are extremely slow. Caching database results was certainly useful to reduce load on the database, but did little to improve the actual performance of the site.

To combat this, we adopted a different caching strategy. Instead of just caching database results, we cached entire JSON responses, keyed on URL. Django's handy decorator for this ( cache_page() ) was limited to TTL-based invalidation, so we wrote custom caching and invalidation logic by overriding methods on our routes. At this point, almost all our heavy-hitting read views were served through the cache, freeing the database for writes. And all of this only took up about ~20MB in Redis!

Results

Penn Clubs had seen complaints in the past about slow performance, especially during peak load - it's always been on our backlog to look at our code more closely. With average homepage load times of about 4-5 seconds, our baseline was undeniably poor.

All of our work led to big boosts in performance numbers. Across the entire Penn Clubs API, we saw a reduction in mean response time from 700ms to 200ms. On heavy endpoints, we saw reductions by a factor of 10. We also saw fewer spikes in the query times, reflecting a lack of throttling despite increased traffic.

Average API response times. Changes implemented on ~Jan 6.

In addition to these metrics, we saw significantly reduced load on our database, with read and write latency improving both about 2x on average alongside reduced variance. Our projected Redis memory usage is also around 500 MB at peak, with an average of 20MB: basically nothing! Given that our average Redis memory usage prior to this was about 1 MB, it is safe to say we were underutilising a hidden gem in our setup.

Conclusion

Perhaps the key takeaway from this blog post is not to (falsely) promise 100% availability. If even AWS can only do 99.99% at best, we shouldn't get ahead of ourselves. This is all to say that Penn Clubs may very well go down again during application season. In that case, you will either find me resigning or jumping down yet another rabbit-hole - I'd rather not find out which.

On a more serious note, Penn Clubs has seen a lot of important design changes and realizations, the primary of which is due to the fact that most of the content we serve is static. The list of clubs, applications, and application submissions (after deadline) all change very infrequently. Given that all our products use a shared database instance, and our applications interact with the database a lot, capitalising on this fact seems to have had the largest positive effect on our performance.

Path@Penn Downtime Post-Mortem

Mon, 02 May 2022 00:00:00 GMT

Over the past month, our infrastructure has had some intermittent issues, so we wanted to drop a quick postmortem describing what the problem was and how we fixed it so we can solve these problems more quickly in the future!

Terminology

Before starting, we should define some terminology:

Pod - one instance of a running application (ex. Penn Courses Backend)
Node - a physical machine that our pods run on
Cluster - a collection of nodes that our pods run on
Kubernetes - a piece of software built to move pods among nodes such that nodes don't get overwhelmed (use too much CPU/RAM)

Background

For our cluster, we use AWS Spot Nodes. These are machines that may, at any time, be shut down by AWS for use in other places. In exchange for this, we pay a lower price for these nodes. Nodes going down is not a problem for us since we're running in Kubernetes which will automatically move our applications to our other nodes if one goes down.

When a spot node goes down, all applications (I'll use the word pods interchangeably) are moved to the other nodes. A new node is then brought up and the pods (hopefully) rebalance between the available nodes.

Additionally, a few weeks ago, we switched from many smaller nodes to 3 higher-resource nodes. This gave us some cost savings as fewer high-resource nodes are cheaper than many low-resource nodes.

Symptoms

Symptoms first appeared around the time of the Path@Penn launch.

We started getting reports of applications failing with no text in the browser other than Service Unavailable. This allowed us to immediately know that this was an infrastructure-wide issue for a few reasons:

If multiple products are failing in the same way, then there cannot be a single-application code change that caused this. It must be that some part of the underlying infrastructure is broken.
Service Unavailable is an error that typically only our load balancer, Traefik will throw. It is almost never sent by actual application code.

Initial Debugging

Upon looking at the cluster with kubectl, we saw that many pods were stuck in the ContainerCreating state. This means that a pod has been assigned to a node, but for some reason, the node cannot start the pod up.

To debug this further, we looked at Datadog, our monitoring system. Datadog showed between 1 and 2 nodes at 100% CPU usage with the third sitting almost idle at ~10% usage.

At this point, the question becomes: If Kubernetes is balancing pods, why are some nodes at such higher resource usage than the others?

Deduction

After further investigation, it looks like the following was happening:

A spot node gets scheduled to terminate
All its pods are drained to the other two nodes
The remaining two nodes don't have enough available resources to host all our pods and spike to 100% CPU usage
100% CPU usage renders the two nodes unusable, and they stop responding to both Kubernetes and Datadog.
Even when the third node comes back online, pods cannot be rebalanced to it because the other two nodes are unreachable due to load.

The underlying cause of this issue is that while 3 nodes is enough for our cluster, 2 is not. When a spot node termination happens, we don't have enough resources to handle the load, and it creates a cascading failure throughout our infrastructure.

Solution

To solve this issue, we've scaled our cluster up to 5 nodes. This should mean that even if we lose a node due to spot lifecycle, we've got plenty of compute to handle things.

Why did this just happen now?

This is the main question we've been asking ourselves. Intuitively, it seems like we should have run into these issues as soon as we switched to only using 3 nodes.

However, these issues are not just a symptom of having 3 nodes. They're a symptom of having 3 nodes while under high load. The Path@Penn launch was the first time we had high load on our products since moving to 3 nodes. Therefore, while this problem existed all along, we didn't notice it until our systems were under stress.

Next Steps

To solve these issues more quickly in the future, we should have better alerting and monitoring around application failures. Specifically:

Alerting when we have a high number of 503 Service Unavailable responses. These almost always indicate an infrastructure-level error.
Alerting when we have high node CPU usage. While pod CPU usage hasn't been great signal for us (pods occasionally spike), high node usage almost always indicates a problem.

Reach Out

If any of this looks like it's up your alley or you wanna learn more about our mission, be sure to email us at contact@pennlabs.org or apply to be a part of Labs! We've got some fantastic teams working on interesting problems with a direct impact on campus.

Creating a Virtual Club Fair: Redesigning & Repurposing Penn Clubs

Fri, 25 Sep 2020 00:00:00 GMT

Team: Eric W. (team lead, developer), Davis H. (developer), Daniel T. (developer), Campbell P. (developer), Lucy X. (developer), Jong Min C. (developer), Lanting C. (developer), Ying X. (developer), Peyton W. (platform), Armaan T. (Penn Labs director, platform), Misty L. (business developer).
My role: Product management, UI Design, Frontend development.
Tools used: Sketch, HTML/CSS, Typescript.

The Problem

One year ago, I joined Penn Labs, student group on campus at the University of Pennsylvania that works on a handful of products that aims at improving student life for students. From a course review tool to a central mobile application, Penn Labs is an amazing group of designers, engineers, and business developers (all undergraduates!) committed to helping students. Last year, Penn Labs launched pennclubs.com, an online directory meant to help students peruse the hundreds of clubs our university offers in a more user-friendly way than their legacy system (which was, essentially, just a list of clubs) had. At the end of the 2019–2020 school year, we secured a partnership with Penn’s official Office of Student Affairs to move the official registry of student organizations onto our platform.

The wake of COVID-19 has created lots of opportunity in the realm of online connectivity: over the summer, I have seen many peers of mine pursue products that aim at filling the gap left by face-to-face experiences. One problem in particular that sparked conversation that arose in mid-July was the annual club fair. Once an exciting event that could best be categorized as exciting chaos, the fair used to take place on Locust Walk, the central, half-mile walking street that could be thought of as the Autobahn or the Route 50 of Penn. Attended by over 500 clubs and thousands of undergraduate students, it has always been an energetic, loud, and exciting day, full of new Quakers trying to find their homes—only to be completely stripped away from the Penn experience this fall.

On August 11, the University of Pennsylvania revoked their previous hybrid model in favor of a fully-online one, changing much of what makes the red-and-blue experience would be like, especially for first-year students who haven’t met their people yet, who haven’t found their communities. We were approached with the opportunity to make sure that they could.

Goals

Provide a platform through which new students can browse university organizations.
Find a way to replicate the on-campus fair process online for a synchronous experience, through a video chatting platform.
Design an asynchronous way for students in different timezones to still interact with clubs in a relatively informal and centralized location.

The Stakeholders & Users

We understood the landscape of the stakeholders we would be dealing with, given our relations with the official offices of the university, including OSA, which is responsible for student life on campus, and the Student Activities Council (SAC), which typically manages the club fair, and handles over $1 million in funding for club each school year.

We identified three key types of users:

New students, typically freshmen or transfer students, as well as some sophomores who want to find new clubs to join. They may know varying amounts of information on certain clubs, and will want to browse clubs in the same manner that they would if we had a live fair, on campus. There are about 2.7k new students on a given year to Penn. It is important to note that 20% of Penn students are international, and live in a wide variety of timezones.
Club officers, who want to market their organizations to prospective members. They want to provide details about their organization, hold information sessions, and find new members to recruit. There are approximately 600 clubs on campus, each with between 1–3 officers on average.
University officials, including representatives from OSA and SAC (who are actually also undergraduate students). They want to be able to manage which clubs can participate in the fair, and ensure clubs are abiding by university branding guidelines. We worked with three of these officials on a daily basis.

These different types of users would need to have different permissions to view the sections of pennclubs.com, as well as different action items that we would need to lay out.

Existing Tools

Penn Clubs, circa August 2019.

Penn Clubs, launched in the Fall of 2019, already had some pretty awesome features. There was a great filtering and search system, a recommendations algorithm that took a student’s school (Arts & Sciences, Nursing, Wharton, or Engineering) and major into account in showing relevant clubs, and the ability to subscribe to a club’s email listserv for updates. Most of these features were in place to reach goal #1 pretty seamlessly.

The biggest tool we wanted to take advantage of was the school wide access to premium Zoom accounts (Eric had actually created a plan to build a video conferencing platform from scratch, but given our tight deadline and the existing access to the system, we figured it’d be wise to just use Zoom). Key features about Zoom include the ability to create breakout rooms for one-on-one or small group interactions, as well as the ability to use a chat feature for students who may feel too shy to come off mute and ask questions.

Further research revealed that we could also leverage the existing Zoom API to make scheduling meetings for the synchronous part of the fair easier for club officers. With settings hidden behind educational accounts, three different dates, and timezone confusion, we wanted to streamline the Zoom meeting creation process by automating this process.

The Asynchronous Problem

As previously noted, there are hundreds of Penn Students that live in timezones that are completely incompatible with American timezones. We wanted to ensure that aside from the scheduled Zoom meetings, there would be opportunity for students to interact with club owners in a less formal setting than sending an email with questions.

Clubs already had the ability to input a handful of information, including a description, basic contact information, a section on “how to get involved”, and select pertinent tags.

We toyed with the idea of having a chat box for each club, where users could interact with club officers — but also knew that this would depend on club officers being on the platform to answer live chats. Instead, we opted for a Q&A feature, taking some inspiration from Reddit’s AMA structure, where users can ask questions (anonymously or not) to club officers, to be answered for all users to benefit from.

Clubs can provide a variety of information, including a description, contact info, a section of how to get involved, and can also answer questions!

Executing the Project

We assembled a team of Penn Labs designers, developers, and business developers who had a couple free weeks of their summers to transform Penn Clubs from a simple database into a fully-fledged product ready to handle events, a club fair, and administrative capabilities.

Three weeks, dozens of Clubhouse cards, hundreds of git commits, and thousands of emails later, we launched the new-and-improved version of Penn Clubs that included dozens of new features, large and small, including:

the ability to browse clubs through four different orderings (alphabetical, random, bookmarked, featured — which rewards clubs for inputting more information for prospective students),
a more mature event creation process, that included Zoom integration and the ability to upload a cover photo,
a live events page, fetching and featuring all current events created by clubs, searchable, and filterable by club tags,
automatic event creation using the Zoom API,
a Q&A section featured on each club’s homepage,
two user guides for the fair (a version for students, and a version for club officers),
an analytics page for club officers to view pertinent statistics such as page views, bookmarks, subscriptions, and the breakdown of viewers on their pages,
and administrative tools for University officials, including approving clubs for the fair, report generation, and more.

Screenshot of Penn Clubs’s live event page

The Impact

Aside from a slight hiccup on our first day when our servers overloaded due to a much higher attendance rate than we anticipated, the club fair ran extremely smoothly. Here are some standout statistics during the September 1–3 period:

642 registered clubs,
128,367 page views,
5,284 users in 84 countries,

and we are still, at the time of writing this in mid-September, averaging approximately 1,000 users per day. Pretty crazy stuff!

The Future

We have several goals we, as a team, are working towards to keep improving Penn Clubs as a platform — we recognize that this platform can continue to be a hub of information for students, well past the period of the club fair. We are continuing to partner with several other offices in the administration, and are excited to welcome a couple more designers, developers, and business developers later this week to continue to mature our product!

Check out the other amazing work that Penn Labs is doing at pennlabs.org!

Icarus: Taming the Kubernetes Beast

Wed, 27 May 2020 00:00:00 GMT

Recently, we've moved our infrastructure from Dokku to Kubernetes as a platform to host and run our web applications. As a student organization (or club) we have a high member turnover rate as new members come and old ones leave. As such, we have to carefully consider the organizational impacts of moving to a technology as complex as Kubernetes. This post should serve as a bit of insight into how we dealt with that challenge and built technology to solve it.

Background

Typically when organizations decide to adopt Kubernetes, their organizational structure takes one of two patterns (or a combination of both):

Pattern 1: Embedded SREs

In this pattern, each team has one or more Site Reliability Engineers embedded in each team. These SREs are responsible for managing the deployment infrastructure and general architecture for the product. Since this model gives teams Kubernetes experts right in the teams, these teams are responsible for managing their own Kubernetes manifests and general deployment strategy.

This system works great for teams with complicated application architectures whose applications might require special features like persistent volumes, cross-datacenter availability, complex scheduling requirements, etc. Think teams running Cassandra clusters, Solr clusters, or database services. In this model, SREs on each team can fit the Kubernetes configs to each team's needs. The clear drawback, however, is that your number of SREs required scales linearly with your number of teams.

Because of the (relative) simplicity of Penn Labs' applications and only having 2-3 SREs to service 5 teams, we determined that this pattern was not an option.

Pattern 2: Platform Team

In this pattern, there is a single team (or organization) that is responsible for building a high-level platform that other teams can use to deploy their applications. Building a platform involves significant up-front engineering work and a strong team to build the automation and interfaces required in order to create a frictionless deployment experience.

This approach typically works best for applications with simple architectures. If you can restrict your applications to have similar architectures, you can build a platform that takes advantage of those shared architectures, abstracting away the common configuration.

In Penn Labs, all of our web applications follow similar architectures: a single frontend (usually React) and a monolithic backend (usually Django). Since we have a common, simple architecture and we don't have the personell to man every team with an SRE, we decided to go with the platform approach. This approach fit nicely into our organizational structure since we already have a platform team that manages our authentication system.

Platform Abstractions

There are quite a few tools that fit together to make this system work (Hashicorp Vault, Grafana, etc.), but for the purposes of this post, I'm going to focus solely on the tool that developers actually use: Icarus.

Kubernetes configs are hard and complicated. Kubernetes aims to be able to support any containerized application architecture possible, so it exposes every knob you could possibly want to turn. In simple setups, this leads to nothing other than repetition and confusion. For example, below is the configuration required to simply deploy our website, our simplest product:

---
# Source: icarus/templates/services.yaml
apiVersion: v1
kind: Service
metadata:
  name: 'testsite-serve'
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: 80
  selector:
    name: 'testsite-serve'
---
# Source: icarus/templates/deployments.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: 'testsite-serve'
  namespace: default
  labels:
    name: 'testsite-serve'
spec:
  replicas: 1
  selector:
    matchLabels:
      name: 'testsite-serve'
  template:
    metadata:
      labels:
        name: 'testsite-serve'
    spec:
      containers:
        - name: 'worker'
          image: 'pennlabs/website:latest'
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80
          envFrom:
            - secretRef:
                name: test-secret
---
# Source: icarus/templates/ingresses.yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: testsite-serve
  namespace: default
spec:
  rules:
    - host: 'pennlabs.org'
      http:
        paths:
          - path: '/'
            backend:
              serviceName: testsite-serve
              servicePort: 80
  tls:
    - hosts:
        - 'pennlabs.org'
      secretName: pennlabs-org-tls
---
# Source: icarus/templates/certificates.yaml
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: pennlabs-org
  annotations:
    'helm.sh/resource-policy': keep
spec:
  secretName: pennlabs-org-tls
  dnsNames:
    - 'pennlabs.org'
    - '*.pennlabs.org'
  issuerRef:
    name: wildcard-letsencrypt-prod
    kind: ClusterIssuer
    group: cert-manager.io

As mentioned earlier, in our applications we can make the following assumptions to make our lives easier:

That application, if exposed to the world, will speak HTTP and want to be secured with HTTPS
That application will use secrets synced into Kubernetes by our Vault secret sync job

With just these two assumptions, we can radically simplify our required configuration to the following for this example:

deploy_version: 0.1.15

applications:
  - name: serve
    image: pennlabs/website
    secret: test-secret
    ingress:
      hosts:
        - host: pennlabs.org
          paths: ['/']

Let's dive into how this is possible.

Helm

At the root of the transformation from Icarus file to full Kubernetes manifest is a tool called Helm. Helm describes itself as a "package manager for Kubernetes", but for the purposes of this article, think of it as a templating tool that happens to be good at deploying to Kubernetes.

Helm operates off the Go template package. This package, much like Python's Jinja or Ruby's ERB, lets you define a template file, specifying where to put information the user provides. Take the example of our service template. This template defines a basic service with parameters:

apiVersion: v1
kind: Service
metadata:
  name: { { $app_id | quote } }
spec:
  type: { { .svc_type } }
  ports:
    - port: { { .port } }
      targetPort: { { .port } }
  selector:
    name: { { $app_id | quote } }

Helm lets you define default values, so in Icarus, we set .svc_type to be ClusterIP by default and .port to be 80 by default. We also set $app_id to be <repository_name>-<application_name>. Applying these rules, we get the resulting configuration that we see above:

# Source: icarus/templates/services.yaml
apiVersion: v1
kind: Service
metadata:
  name: 'testsite-serve'
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: 80
  selector:
    name: 'testsite-serve'

Icarus works simply by applying substitutions like this to create the final Kubernetes manifests, and then we use the DigitalOcean API to automate the deployment of these manifests to our actual cluster. I'm glossing over a lot of detail here, but feel free to check out our deploy orb for the specifics.

End Result

There's been a lot of talk here about organizational philosophy and YAML templating, but let's circle back to what this system actually gives us.

When one of our developers wants to create a new application, they can, completely independently, create a Git repo, add in a small CI config file, create their Icarus file, and add their proper secrets into Vault. Once that's done, they can push upstream to Github, and their application will be published to the domain they specified in their Icarus config in just a few minutes. If you ask me, that's pretty cool.

Reach Out

Year in Review: 2019-2020

Sat, 23 May 2020 00:00:00 GMT

Hi there! I’m Davis, the outgoing Director for Penn Labs this past school year. Recently, I’ve been thinking back on the year we’ve had, and how lucky I’ve been to be able to be a part of Penn Labs during this super exciting time in the organization’s devlopment. Even with everything going on in the world right now, we’ve accomplished so much as a club this past year. I thought it would be a good time to take a more official look back and highlight the amazing things Penn Labs members have done. Hopefully, this can start a trend where the outgoing director takes a big-picture look backwards at the end of their tenure.

By the numbers

We are a technical club, and we do love data, so I thought I’d start off this review with some cold, hard numbers.

Recruitment

This club is nothing without the people that make it up. After our most intense and selective process yet, we welcomed thirty-six new members between our Fall ’19 and Spring ’20 classes. Our fall class alone doubled the size of Penn Labs.

This kind of explosive growth has its challenges, but we’ve been able to take them in stride, and our new members have done amazing work for their product teams and accross the organization.

Product Growth

Alongside our team, our products have also seem super amazing growth this past year. The section below points out a few big highlights.

Penn Courses

Our course registration products are used most heavily during the registration period around when schedules are being released. During that time, two of our established course products saw pretty amazing growth.

Penn Course Alert was started in Fall 2017 to help students more easily discover when courses have opened up for registration. The service’s userbase has grown steadily since then: each new freshman class brings a new opportunity for new users, who haven’t yet formed habits with other services. This year, we had a whopping 290% growth year-over-year in the days after schedules were released.

Penn Course Review is the website that Penn Labs was first built around. Even though it’s been around for ten years, we’re still seeing growth among graduate students, faculty, and the undergraduate population. Usage during registration grew 24% year-over-year, which is pretty amazing for a tool that’s already ubiquitous in the student body.

Penn Mobile

Penn Mobile has always been one of our most well-known products, and this year we’ve added integration with your dining plan and an amazingly beautiful re-design on Android. On iOS, Penn Mobile has seen 70% year-over-year growth in its weekly active users, and on Android there’s been about 20% growth year-over-year!

New Things

It’s truly crazy how many new things we’ve launched this year, but I’ve tried to give space to them all. Hopefully, many of the items mentioned here will get their own blog posts some day!

Business Development Team

The BizDev, role was piloted during the 2017-2018 school year, but ultimately not continued for reasons chronicled in this article from our archives. But if at first we don’t succeed, we certainly try again. BizDev was rebooted this year with a focus on outward-facing projects, encompassing everything from marketing to stakeholder relations to product management. Our BizDevs have been a core part of our success over the past year, and I’m excited to see how the role evolves in the future.

Penn Mobile Portal

The Spring of 2019 saw the indroduction of Penn Mobile’s homepage, which allowed users to see an at-a-glance view of all parts of Penn Mobile. We wondered how we could give groups around campus the ability to leverage this platform, and the Portal is our answer to that question. It’s been in beta this past year, but look for a general release in the next school year!

Deployment Infrastructure

Up until this Fall, all Penn Labs products were running on a single server. As we added more and more products that were serving more and more users, we realized that we needed a total overhaul to keep up with our growth. Our Platform team put together a really awesome system built on top of Kubernetes that will allow us to continue to scale out as we grow!

Penn Basics

Penn Basics has been in the works since 2017, and finally was released in the Fall of this year. As a web-first view into all kinds of information at Penn, Basics has a real opportunity to give students tons of detail into resources around campus.

Penn Clubs

Penn Clubs began as a partnership between Penn Labs, the UA and SAC to provide a way to discover clubs on campus that is much less stressful than the in-person club fair. After a crazy fun hackathon, we launched the day of the fall club fair, and ever since we’ve kept working with our stakeholders to improve the experience for students, club officers and administrators.

Penn Course Plan

Last year, we took over Penn Course Search from a graduating senior. After over a year of work, we re-designed the product from the ground-up and rebranded as Penn Course Plan. You can read a lot more about the design process in Jess’s amazing writeup.

Partnerships

We’ve always had a tight relationship with the University, but this year we’ve strengthened existing ties and reached out to create new ones.

OSA

The Office of Student Affairs has been an amazingly strong advocate for Penn Labs in recent years. With the development of Penn Clubs, we’ve had the opportunity to work even closer with the OSA to shape the future of how students and leaders interact with clubs on campus and the administration.

NGSS

For the first time in almost 30 years, the University is replacing Penn InTouch with a new system. Penn InTouch is most students’ main interaction with course registration and academic planning, areas in which Penn Labs is heavily involved. We’re greatful that the University has brought us to the table in discussions surrounding the Next Generation Student System, and it’ll be exciting to see where this initiative goes over the next two years.

Wharton Computing + CETS

This year, we’ve sought to reach out and strengthen connections with Penn’s various IT organizations, specifically Wharton Computing and CETS within the Engineering school. Both of these organizations support a wide array of infrastructure that students use every day, and by opening up a line of communication, we can look for ways to better serve students while leveraging what groups have already built.

Cornell DTI

In recent months, we’ve been involved in a knowledge exchange with Cornell’s Design & Tech Initiative, an organization with a similar mission to Penn Labs. While our clubs are different, it’s been extremely illuminating to learn about how DTI designs and develops products.

Internal / Social

First Retreat

Right after our Fall newbies joined, we went on our first ever retreat to Chamounix Mansion just north of campus! It was a really great way to get to play some boardgames (shoutout to Catan and Codenames) and get to know everyone outside of our usual environment.

First Formal

In December, we expanded our end-of-semester team dinner to a full-on formal! Labbies could bring a guest to a great evening of dinner and Dave & Busters.

Conclusion

A year is honestly a really long time, and so this post shouldn’t serve as anything more than an overview. But we’ve been able to do some amazing things for the Penn community since last May. There still are challenges ahead: we’ve grown quickly, but we’ve been able to maintain our sense of self and our sense of community. As time goes on, it’s important for us not to forget what makes Penn Labs special.

I want to thank Valencia for being such an amazing mentor and partner, teaching me so much this year. I also want to thank Armaan for being an awesome co-director this past semester – I know that him and Marta are going to do amazing things this next year!

Signing off,
– Davis

The Design of Penn Course Plan

Tue, 04 Feb 2020 00:00:00 GMT

This article was originally posted here.

TIMELINE Feb - Nov 2019 (10 months)

ORGANIZATION Penn Labs

TEAM Davis Haupt (Team Lead + Developer), Ying Xuan Eng (Developer), Daniel Like (Developer), Shaya Zarkesh (Developer), Daniel Tao (Developer), Charley Cunningham (Developer), Daniel Ng (Business Developer)

MY ROLE User Research, Experience Design, Interface Design, Visual Design

TOOLS Sketch, Zeplin, Figma, Illustrator, HTML/CSS

BACKGROUND Designing for the Courses team, I work closely with developers to build products that streamline course registration for students.

In 2017, Penn Labs acquired Penn Course Search, a former Penn student’s side project. At the start of 2019, we initiated a complete interface redesign, back-end rewrite, and rebrand of the product as Penn Course Plan. In October 2019, we launched Penn Course Plan in time for Spring semester course registration.

As the only designer for this project, I was responsible for discovering user needs, designing the new interface, creating a style guide and component library, and handing off detailed mockups to developers.

The Problem

Course registration is a complicated and tedious process.

When students plan their courses for the upcoming semester, there are many important factors to consider. However, pertinent information is decentralized across many resources.

The university’s course planning software Penn InTouch is notoriously difficult to navigate and forces students to reference external tools. Penn Course Search addressed some of these shortcomings, but fell short on critical features and user friendliness.

Penn undergraduates need a more comprehensive and intuitive course planning tool to simplify the complicated course registration process.

Approach

Solution

We built Penn Course Plan, a web app that allows students to find and plan their courses for the upcoming semester, combining a comprehensive course search with a simple mock scheduling tool.

Penn Course Plan aims to help students feel more informed and confident when choosing courses, while efficiently and intuitively creating mock schedules.

Search for courses and create mock schedules

Look for courses to take next semester and keep your options in your course cart. Plan your schedule by adding courses from your cart to multiple mock schedules.

Filter and sort search results

Efficiently find classes that fulfill general education requirements and double count. Additionally, filter by quality, difficulty, course units, and type. Sort classes by difficulty and course quality.

View relevant schedule statistics

Get an overview of each mock schedule with average quality, difficulty, and workload. Manage your time with stats on total credits and hours of class time.

Research

DEFINING TARGET USERS

Who are we designing for?

Considering the immense diversity among the 10,000 undergraduate students at Penn, it was important to identify subgroups within the population to understand their unique needs, motivations, and pain points.

Penn has four individual undergraduate schools. Coordinated and uncoordinated dual degree programs (multiple schools) are not uncommon at Penn. While all students choose from the same course offerings, each school has their own graduation requirements.

Additionally, course planning considerations vary significantly between freshmen, sophomores, juniors, and seniors.

You are not your user

At Penn Labs, products are built for students by students. While acting as everyday observers of campus life makes it easier to empathize with our target audience, it poses its own challenges.

It was quick and convenient to test and gather feedback from Labs members at each step of the process, making it easy to fall into the trap of assuming that we are representative of the target audience. This would be a dangerous assumption, since our members tend to be more tech savvy and motivated to use our products than the average user.

Throughout the redesign process, I made an effort to frequently gather feedback from and conduct usability tests with a broad spectrum of users to obtain authentic and unbiased feedback.

USER RESEARCH

Talking to People

I talked to many students across several demographics, including graduation year, school, intended field of study, and familiarity with Penn Courses products. The general interview protocol involved asking questions that would help me understand how students currently plan their courses and what problems exist in the process.

What factors do you consider when deciding what classes to take?
What resources do you reference when you’re planning your schedule?
What’s your process for creating a mock schedule?
What’s your biggest challenge when planning courses for next semester?
What are the most helpful and frustrating features on Penn InTouch?

Synthesizing Online Data

To better understand student needs, I analyzed the different curriculums and graduation requirements for each undergraduate school using their course planning worksheets. I synthesized the results into key findings for each school. I also gathered comments about Penn InTouch from students who expressed their criticisms in the Daily Pennsylvanian and a published document by the Student Committee for Undergraduate Education. I found that students were frustrated by the inconvenience of navigating to multiple tabs to find the information they needed. There was also** lack of trust** in the software due to the outdated interface and the buggy experience.

Key Findings

Taking note of the patterns that emerged from the various research methods, I identified the following pain points in the course registration process:

Students take many factors into consideration when constructing their schedule, but all the information they need is spread across many different sites and tools.
Penn offers thousands of classes, and students have trouble narrowing their choices.
Students are unsatisfied with the current resources (Penn InTouch and university academic advising) but some are unaware that other resources exist.
It’s tedious to build mock schedules on Penn InTouch because searching for courses and viewing them in mock schedules requires toggling between multiple pages.

Because of these difficulties, course planning as it stands now is frustrating and stressful process.

IDENTIFYING NEEDS

Crafting User Personas

From the research, I constructed a few personas to represent target user groups and explored their needs, frustrations, and end goals.

Establishing Design Goals

With the user research insights and personas in mind, I worked with my team todecide which user pain points and business goals to tackle before the October launch. Here are the primary goals we decided upon:

Enable users to effortlessly and efficiently access the data they need to construct an informed course plan.
Make it easier to find classes by designing an intuitive, unintimidating course search experience
Structure the site in a way that seamlessly bridges the course search and mock schedule functionalities.
Create a visual style guide and component library that dictates interactive states and technical specifications for developers.

If the goals have been met, we can help users feel more informed and less stressed while planning out the next semester and integrate Penn Course Plan within the Penn Courses ecosystem.

Ideate

EXISTING SOLUTIONS

Auditing the Current Version

With what I learned about our users, I determined what features from Penn Course Search to keep, improve, create, or get rid of.

Keep layout order. Search, results, then schedule is a logical order to users.
Improve search filtration. Filters are hidden from the default display and applied filters are not displayed upon search.
Improve schedule hierarchy. Organize arrangement of schedule management actions. Display courses on the calendar in an accessible manner.
Improve display of search result. Make section details scannable. Find an accessible and efficient way to visualize rating values.
Add more filtration capabilities. Incorporate highly requested filter options (i.e. quality, difficulty, time, credits).
**Add schedule statistics. **Display data visualizations of that provide statistical overviews of mock schedule difficulty, quality, workload, and time.
Remove underused features. Import schedule and filter by special programs required lots of technical resources and were used by less than 2% of users.

Competitive Analysis

Penn InTouch

I first took a look at Penn InTouch, the university software that all students currently use to search for and plan their courses. adding a course to my mock schedule on PennInTouch

The main pain point of building schedules in PennInTouch is the need to toggle between multiple pages (‘Course search’ and ‘My mock schedules’) when creating the mock schedule.

Users must search for courses on the search page, add the courses they would like to put in their mock schedule to the course cart, then switch to the mock schedules page to add courses from the cart to the mock schedule.

Coursicle

Because the university’s software Penn InTouch fails to address key user needs, students have turned to non-university affiliated options. Penn Course Plan’s direct competitor is Coursicle, a site that features course catalogues and schedule builders for hundreds of universities.

While Coursicle’s objective is to provide a “less stressful” and “more modern” alternative to “slow, unintuitive, and ugly online systems,” it falls short in delivering user-friendly interactions and comprehensive course data. Pros:

sleeker interface than Penn InTouch
enables efficient management of multiple mock schedules
side by side placement of search results and mock schedule

Cons:

separates course search and schedule creation onto two different pages
contains two separate mechanisms for adding courses to the schedule
lacks sufficient information about courses and sections
missing critical course filtration functionality
poor hierarchy in search results and course details

Because Coursicle services so many universities, it does not address the specific needs of Penn students. I summarized the main opportunity areas that Penn Course Plan can address:

Search and schedule are still on separate pages, requiring the same frustrating toggling behavior as Penn InTouch.
Critical information that students take into account when deciding upon courses, such as student reviews and course descriptions, are not displayed. Additionally, there are no warnings for co-requisite sections.
Search filters are not comprehensive. The filters only cover general education requirements for College students, missing Engineering/Wharton/Nursing students.
The search results are cluttered and do not display information students care about hierarchically.

BRAINSTORMING

Ideating Features

After establishing the design goals and gaps in existing solutions, I brainstormed ideas to address those gaps with my team, prioritizing based on importance to users **and feasibility**.

Working with Constraints

By talking to developers during ideation, I was able to uncover technical constraints and compromise early on. We determined which features were feasible to implement before our launch, which were feasible to implement eventually, and which were not feasible at all.

We settled on the following major features for the initial redesign:

**Course search: **Search for courses by course name, department, and professor. Sort search results.
**Search filters: **Keep existing filtration capabilities. Incorporate filters that rely on Penn Course Review data and compatibility with the existing schedules.
Section details: View course section details in scannable table cells. Add sections to the cart.
Course cart: Store course sections in the cart to be added to multiple mock schedules.
**Mock schedules: **View course sections in calendar format. Manage (create, copy, and delete) schedules.
Schedule statistics: View relevant data that gives an overview of mock schedule parameters.

Some features that we** eventually hope to implement** include:

Filter by major: Major requirements are housed on each department’s website, and are not formatted consistently across departments. This makes it difficult to implement this feature without extensive manual input.
Academic worksheets: Academic worksheets on Penn InTouch are customized course checklists based on a student’s chosen academic plan. However, because these checklists are based on major requirements.
User accounts: Penn Course Plan is now moving all its products towards an accounts system to save user information in their PennKey login.

These features were tricky to deal with, since I had to keep their potential entry points in mind while laying out the initial interface.

Design

SKETCHES AND WIREFRAMES

Crafting the Layout

I started the design process by sketching to explore the layout and placement of several features. I collected qualitative feedback from my team members and other students throughout this stage. After receiving feedback on these initial explorations, I made the following design decisions concerning the layout:

Keep the course search on top, but separate it from navigation, to group it visually with the sections below.
Combined the search results with section details to reduce redundant information and make room for a course cart.
grouped the schedule management functions with the mock schedules.

I then created mid-fidelity wireframes to finalize the layout to determine where the search filters and academic worksheets would go. A features a search section (filters, search results) and a schedules section (cart, mock schedules). While organized simply, I found it difficult to make responsive without dramatic changes.

B is more modular, with separate search, results, cart, and schedules sections. The layout is more complex than A, but the flow remains intuitive.

C retains the layout of B, but features worksheets on a slide out section. While this allows users to use the worksheet while viewing the other functions, it limits the amount of space available for the worksheet features.

I settled on B, since the tabbed navigation allows for more flexible feature additions than C and the modular layout is more responsive than A. After deciding on B, I began exploring the individual features in more detail.

DEEP DIVES

Search Filters

In the current interface, search filters are hidden from the default display and applied filters are not displayed upon search. By observing users, I learned that this interaction caused confusion when filters that were applied earlier yielded empty search results. This confusion led to frustration and lower trust in the course search feature.

Determining structure

First, I explored two ways to increase the visual prominence of the filters: a vertical sidebar and a horizontal toolbar. A is easier to skim and unrestricted by page width. However, I found that seeing all the filter options at once is not helpful enough to users to justify the amount of space the sidebar requires.

I decided on B, since it increases visibility of filter options in a compact and easily discoverable manner.

Defining interactions

I studied the way products like AirBnB and Google Fonts handle search filtration interactions. I found that distinctive interaction states were essential for creating an intuitive search experience.

AirBnB replaces category labels with selected values. With this design, users can see exactly which filter values are selected. I experimented with this approach for Penn Course Plan’s filters. AirBnB replaces category labels with selected values. With this design, users can see exactly which filter values are selected. I experimented with this approach for Penn Course Plan’s filters. However, I learned that this would not work for several edge cases, such as multiple long category values and categories with the same value types. Google Fonts replaces category labels when one value is selected, but not multiple. In all cases, changing in the filter background color and addition of the X button make it clear to the user which filters have been applied. I explored a similar approach for Penn Course Plan’s filters. This design resolves the usability issues from the previous iteration. Although selected filter values are not readily displayed in this design, users found the distinct interactive states sufficient for conveying this information.

Filter category dropdowns

I designed dropdowns for the current filter categories: school requirements, section type, and course units. I added filters for course difficulty and quality ranges, based on Penn Course Review data. Additional filters I considered including were time range, open/closed status, and compatibility with the selected mock schedule. These were not technically feasible to implement before launch.

Clarifying the empty state

I also designed an empty state for when applied filters cause the search query to return no results. The distinct illustration and guiding copy clarify the situation.

Course and Section Information

Displaying the details for each course was the biggest challenge in the redesign. From user research, I learned about the many factors students take into consideration while choosing their courses.

On Penn InTouch, section details are displayed in a dense horizontal table with modals for additional information. On Penn Course Search, the course and section information are displayed in two separate panels. The section panel contains a table with a row for each section, showing additional details when clicked. For both Penn InTouch and Penn Course Search, it takes at least three clicks across two different areas to uncover all the details students use to make an informed decisions about courses.

My strategy was to condense course information into simple table cells while maintaining pertinent details. I focused on establishing visual hierarchy and scanability.

Course search flow

For each course at Penn, there are several associated sections (i.e. lectures, labs, and recitations) that students can choose from.

When users enter a general search term (i.e. “CHEM” or “algorithms”) the search results will include summarizing parameters relevant to all sections of the course.

When users click on a general search result, or if they enter a specific search term (i.e. “CHEM 101” or “Introduction to Algorithms”) they will be shown more details about the course, as well as information on the individual sections.

Course summary view

I started by designing the general search results, which display information relevant to all sections of the course: course number, course title, quality, difficulty. A key design decision I made was to change the visualization of the quality and difficulty metrics to be consistent with Penn Course Review’s color system. A is based on Penn Course Search’s system, which uses opacity to denote quality and difficulty levels (low rating = low opacity, high rating = high opacity).

B is based on Penn Course Review’s system, which uses three discrete colors to represent three levels (low, medium, and high).

In C, I considered using green for high quality/low difficulty and red for low quality/high difficulty, since many students are actively looking for good and easy courses. However, I was told that the University administration took issue when PCR considered doing this in the past, since they were concerned that users would associate green with good and red with bad.

I went with B, since I found that users could more easily distinguish between the different colors used by PCR than the different opacities used by PCS. To account for this tradeoff made by forgoing** C**, one of the developers implemented a “good and easy” sort to rank the results by descending quality and ascending difficulty.

Section details view

I then designed the section details display. This view contains the entry point for additions to the course cart.

I first divided the section information methodologically based on whether the parameters were relevant to all sections or if they were specific to individual sections.

all sections: course quality, course difficulty, requirements fulfilled, instructor quality, prerequisites, cross-listings, course description
individual sections: section number, section instructor, instructor difficulty, meeting time, meeting location, open/closed status

I chose to display the information for all sections at the top. B **includes the course quality and difficulty metrics missing from **A and has a visual style more consistent with the rest of the product.

I noticed that users did not realize the prerequisites and cross-listings were clickable in B, so I transformed them into links in C. Since quality, difficulty, and requirements fulfilled are not clickable, I transformed them into tags. I also added a link to the course’s Penn Course Review page and a collapsed course description below.

Information for individual sections is displayed below the information for all sections. I explored two alternatives for this table. A displays most of the section details in a single line table, with additional information (i.e. section instructor, meeting location) displayed when a section is clicked.

**B **displays all the section details in a two-line table. Section number and instructor are highlighted in the first row and all other details are placed below.

From user testing, I learned that people found the extra click view additional section information in A to be a nuisance. They preferred seeing the expanded view for all sections as the default in B. In this view, section number and instructor are emphasized. However, referring back to what I learned from users, many other factors (meeting time, section type), were just as—if not more—important to them.

I was also surprised to learn that users found it difficult to locate instructor name, although it was the most visually emphasized parameter. To resolve this confusion, I added icons to label each parameter. Additionally, I moved the instructor quality badge next to instructor name and moved meeting time next to meeting place.

I adjusted the table to display the full course code (not just the section number) in bold, since users enter the full code when they register for courses on Penn InTouch.

Mock Schedules

After users add course sections to the cart, they can then build mock schedules with the added sections.

Mock schedule management

In the current interface, all of the mock schedule functionalities are collectively hidden in a dropdown in the navigation bar. To increase the visual prominence and accessibility of these options, I first experimented with displaying all the functionalities across the top of the schedule. However, I found it overwhelming and unhelpful see all the features all the time. I decided that a dropdown of some sort would be necessary to organize the features.

To better organize the mock schedule features, I categorized them based on their use cases:

Clear **/ import / download** (used during or after the creation of new mock schedules) are placed above the current mock schedule, displayed while the user is viewing the schedule in view.
New **/ rename / duplicate / delete** (used while editing or creating mock schedules) are condensed in a dropdown, displayed when the user hovers over a specific schedule.

From user testing, I learned that many users did not know how to make multiple mock schedules in this design, since the action was nested in a small arrow next to the title of the mock schedule.

Instead of using the mock schedule name as the section header, I decided to use “Mock Schedule” as the default header. I increased the size and prominence of the dropdown by placing the mock schedule name beside it. I also added a new schedule button outside this dropdown. We plan to do A/B testing to see whether this design will increase creation of multiple mock schedules.

Schedule statistics

The team lead and two developers were working on implementing relevant statistics for each mock schedule. I decided how to best visualize this data.

For the course review metrics (course quality, course difficulty, instructor quality, average workload), I explored two alternatives. A shows the number only, with arrows to reflect changes. **B **shows the number with a circular progress wheel. At first, I thought the wheel might be providing redundant information, but I learned that users found it helpful to see changes in the wheel after adding/removing sections from their schedule.

REFINING THE DETAILS

Integration with the Penn Courses ecosystem

One of the key business goals for this redesign was to better integrate Penn Course Plan with the rest of the Penn Course products.

Penn Course Alert

Penn Course Alert allows users to sign up for email and text alerts for closed sections. In the redesign, the bell symbol in the section details view indicates the section is closed.

Clicking the bell redirects users to Penn Course Alert, with the fields auto-populated with the section information. A blue bell indicates that a section is closed and the user is currently already signed up for alerts.

Penn Course Review

Penn Course Review provides extensive student rating data throughout the years. Because this data did not fit within the space and technical constraints of Penn Course Plan, the Penn Labs directors made the executive decision to keep the two products separate.

I added a button inside the course overview as an entry point for the corresponding Penn Course Review page.

Improving clarity

Empty states

I created branded empty state illustrations for each section and provided instructional cues. The copy encourages engagement with the product and reduces confusion.

Tool tips

In addition to empty states, providing guiding information through tool tips clarifies any ambiguities and informs users of any errors.

For example, to ensure users add all the required sections for a course to their schedule, there is a warning icon with a tooltip to let users know if they’re missing the co-requisite section. When the tool tip is clicked, users have the option to add missing sections in the cart directly to the schedule. If the section is not yet in the cart, the section gets added to both the cart and the schedule.

Making it responsive

I designed mobile and tablet layouts to make searching and planning accessible on devices and windows of all sizes. I decided that a tabbed navigation would be the best way to navigate through the search, cart, and schedule on smaller browser windows.

Reflect

IMPACT

By the numbers

We successfully launched this redesign late October 2019, prior to the advanced course registration deadline at Penn.

The product garnered nearly 2,000 unique users within a week of launching, with nearly all users reporting that Penn Course Plan is more user friendly than PennInTouch, the current course registration software.

Throughout the spring course registration process, there have been 8,000 users, many participating in multiple sessions.

Testimonials

My team and I received many personal messages from friends, expressing their gratitude to Penn Labs for making this product. We also received several testimonials from our anonymous feedback form at the bottom of the site:

LEARNINGS

Challenges

This was my first major product design project, and I definitely learned a lot while working with my team to execute the design. A few of the key challenges I faced include:

setting aside my own assumptions about user behavior and needs
making significant alterations based on recurring user feedback
fitting a large amount of information within a single page, no-scroll app
accounting for the many potential edge cases

Next Steps

As new technical constraints, user concerns, and business goals are uncovered, we’re continuing to fix bugs, enhance functionality, and identify areas of improvement. Some of the next steps the team and I have planned include:

conduct further user research to understand the full course planning cycle and timeline
use A/B testing to see what designs increase the creation of multiple schedules
modify the course cart deletion process to reduce confusion
make it easier to compare metrics across schedules
add course planning worksheets and 4 year academic planner

Moving forward, we will be iterating off feedback and making informed design decisions based on user data. We will be expanding to include new features that allow for long-term planning. I’m looking forward to diving deeper into the course planning problems students at Penn face and working with my team to address those pain points.

Conclusion

Designing for Penn Labs has been an extremely rewarding and educational experience. As a student designing a product for other students, I had the opportunity to learn about the course planning pain points and experiences for a wide variety of students.

Working closely with several software engineers and business developers taught me how to design based on user insights, technical constraints, and business goals.

This redesign project was my first time working through the entire product cycle, from ideation to delivery. I can’t wait to continue improving and expanding Penn Course Plan as we continue to hear feedback from the Penn community!

Penn Course Review Technicalities

Tue, 28 Aug 2018 00:00:00 GMT

This article was written by Brandon Lin.

This article is a continuation of a previous article about Penn Course Review’s new redesign. See here for that article.

A monolithic project

Maintaining Penn Course Review was never an easy task. Being one of Penn Labs’ most well-known products and having one of our largest codebases, working on the project was a massive undertaking. Nevertheless, the fantastic developers at Penn Labs helped make the new makeover possible.

This article serves to highlight some of the technicalities of the new makeover.

About Penn Course Review

Penn Course Review is primarily written in Python, using the Django framework. Both the front end and the back end rely on this framework, while all of the data is stored in a MySQL database.

We’ll go over the front end and the back end components separately here.

Front End

We’re redesigning the Penn Course Review experience to make it easier and faster for you to find the courses you need.

Page Size

We thought about how inconvenient it was to scroll through a really long page to find a professor. With jQuery DataTables, we were able to condense most of the information down into a simple, intuitive format that lets you scroll through professors with ease.

This also led us to put the individual ratings and comments in a separate card, so that you don’t have to constantly scroll in order to view different ratings between professors and courses.

Back End

Regarding the back end side, most of our work involved cleaning up legacy code that ran on an old version of Django and providing more documentation to the existing API endpoints. We also introduced Sentry error logging to make it easier for future developers of the project to work on it more easily.

API Refactor

We refactored the majority of the API to conform to Django standards and make the API more RESTful. With the new Django update, we had to conform to these new standards with new endpoints and better code style. Previously, many endpoints were nonintuitive and didn’t follow these standards. We added several endpoints that, for example, allow you to fetch all history about a course.

DigitalOcean Migration

We moved all of our production code to DigitalOcean from an old server that sat in the STWing area in King’s Court. We wanted to make our service more reliable and migrating everything to DigitalOcean gave us the scalability and control that we needed. The old server suffered from a majority of outages and disk breakages that would render the server inaccessible, and we decided that moving to DigitalOcean would be the best bet.

Massive Data

The big challenge that Penn Course Review has faced over the years is how to deal with the massive dataset containing course and professor ratings/comments. With a ton of ratings, loading a single webpage and compiling all results from the database for that webpage would take quite some time.

Traditionally, the solution has been to generate static webpages for each course and professor separately (in a process that takes about 9 hours), so when users fetch a webpage, it’s as simple as getting a pre-generated HTML file.

Obviously this wasn’t very storage friendly and severely non-scalable if we ever want to make any quick changes/bug changes to the website. We were looking for a way to allow for easy website changes while keeping the user experience as fast as it was previously.

The best way to mitigate between these to was to configure our server to cache the page generation whenever a new page request comes in; this way, we don’t hog server space and we can still deliver pages quickly for very popular courses (such as MATH 114). The cache is set to reset every day. This way, we can seamlessly make changes to the site while being able to give the same user experience.

Shibboleth

We also transitioned over from Penn’s old authentication system, Cosign, to their new system, Shibboleth.

Conclusion

Thanks so much to the Penn Course Review team and all of the developers and PM’s at Labs for making this revamp possible; special shoutout to Tiffany Chang and Josh Doman for being fantastic directors and mentors for this project.

The Course Review Got A Makeover

Mon, 27 Aug 2018 00:00:00 GMT

This article was written by Tiffany Chang.

Meet the new Penn Course Review.

🚶‍Down memory lane

The student-run Penn Course Review has served as a valuable guide for course selection since the 1960s. From paper book to web app, it continues to provide course statistics to better inform students during course selection. Penn Course Review was a student club motivating insight-driven course selection. With even more energy, Penn Course Review is now developed and managed by us, Penn Labs, a group of students passionate about solving problems at Penn through technology.

In 2010, Penn Course Review was launched with a sleek, simple, and sexy design. How sexy was it? Let’s take a look at how we’ve been using it.

📊 Quick stats

🤷‍ But it’s not perfect

As time passed, we received comments, critiques, and complaints. No worries, we heard you, and we’re so glad you took the time to tell us what you wanted. After reviewing years of feedback, hearing your complaints in Van Pelt, and watching friends struggle with clunky excel sheets to optimize course load, we realized there was a lot of work to do. We decided to focus 2017 on building a better experience around you.

👋 Meet the new Penn Course Review

We’re so excited to finally announce the new Penn Course Review, a new experience with the same promise. With added features, simplified views, and (for our technically savvy folks) a new stack for performance and efficiency optimization, we hope you enjoy it as much as we enjoyed building it for you.

✨ New UI: We’ve recently updated our design guide and have begun syncing our product designs across the board while maintaining key Penn Course Review interactions. We hope you enjoy the simple, sweet, and complete interface.

🛒 Course cart: Add courses to your cart, compare, contrast, and get insights on your entire semester’s course load. Include and exclude classes to see how your ratings change with and without a course.

🔍 Search within course or professor: We’ve added a search bar within the course table to help you find the specific course/professor/anything you’re looking for.

👩‍🏫 Department view: Trying to decide which FNAR course to take? Take a look at the department view and get a cross-section of all FNAR courses. Use our handy quick course comparer to see your options side-by-side.

🚨 Get alerts: It’s easier than ever to stay updated on a course’s status. Penn Course Alert is now connected with Penn Course Review in just one click. Check if a course is open, and if not, be the first to know when it opens.

🎨 Color calibration: Ratings are color coded.

💛: < 2
💜: < 3
💚: ≥ 3

☁️ Cloud: We’ve migrated Penn Course Review from a physical server to the cloud to optimize speed and performance.

For a technical deep-dive on the update, see this article.

🙏 Special thanks to the team

V.2018: Brandon Lin (PM/Backend Developer), Cassandra Li (Frontend Developer), Eric Wang (Fullstack Developer), Josh Doman (Director), Suzanne Knop (Frontend Developer), Tiffany Chang (Director/Designer), Vinai Rachakonda (Backend Developer), Yonah Mann (Backend Developer).
Our legacy: Adel Qalieh, Adam Domingoes, Alexey Komissarouk, Ceasar Bautista, David Lakata, Derek Jobst, Greg Terrono, Kyle Hardgrave, Matt Parmett, Nop Jiarathanakul, Prakhar Bhandari, Reika Yoshino, Sumit Shyamsukha, Vivek Panyam, Yefim Vedernikoff.

It's so FLUFFY.

Sat, 24 Mar 2018 00:00:00 GMT

Background—

X is an integrated services provider for an elite university in the United States. Formed originally as a conglomerate of various individuals working on independent projects to enhance the lives of university students, the group began to formally affiliate itself with the school name in 2010.

For much of its founding years, X sustained 10 or so employees. Directors were sourced externally to not interfere with the technical work. At the time, the developers themselves were more interested in creating new projects in an effort to jump start a new organization off its feet as opposed to considering the various management details of sustaining an established one.

Near collapse —

A year ago, a sudden drop in participation shoved X to the brink of survival, and the task fell on the shoulders of the remaining members to keep the organization running.

Faced with the prospects of having to completely disband, they broke down the most prominent concerns that had beleaguered their beloved group.

The biggest problems that had arisen was a disconnect between products and their purposes. Since X was founded by students joining together to work on their common, university-related side projects, the organization had been a place for developers to spend their free time experimenting. However, as the key members left, the flow of new project ideas slowed and along with it, focus and motivation.

Finally, there was one more major problem: employee pay. Paying developers had created a budget limit to bring in talent. Furthermore, their work had resulted in a culture of working-for-pay, which at times clashed with working for the benefit of students.

Growth —

Since the organization needed people — and a lot more of them — two members decided to channel their revival efforts at first through recruitment. They knew that more labor didn’t always lead to better results so they were meticulous in the people they brought on board the following semester.

Members were chosen by specific skill sets and passion for improving the Penn community. Employee pay was abolished. Once hired, new members were placed onto the product teams where those exact skill sets were most needed. Each team would have its own set of back-end, front-end developers and designers. The back-end worked on the API and functions of the product while front-end and designers worked closely together to bring about an engaging user experience. The two co-directors each led their own product teams as well as played the director role of making sure each project progressed steadily.

Looking beyond —

With several well-established products on their way and respective teams established, co-directors A and B once again looked to enhance the labor force of the group. Traditionally, members had always been technical in nature and purely focused on product creation. Thus, one of the problems that the organization has faced from its outset was a lack of marketing and commercialization. Products were often inconspicuously released without any promotion or advertising and the organization was dormant on social media. Many students remained unaware that X is responsible for the applications and services they used daily.

Realizing they had access to an abundance of consumer-minded talent for operational decision making and marketing, the co-directors decided boldly to recruit the organization’s inaugural Business Development (BD) team.

Fall of BD —

However, as they soon found out, merely having a Business Development team is not enough. Throughout the semester, they watched as the BD team struggled time after time to integrate with the other product teams and find purpose. The isolated nature of the product teams along with fuzzy launch deadlines created an awkward, out-of-place and out-of-work situation for the BD group even though there was actually so much for them to do. Marketing endeavors that BD tried to take on turned out uncoordinated and sloppy. In fact, members within the organization itself were even unclear of the BD role. Something needed to change …

So, this “X” — a Crunchbase startup looking to scale? Not quite (yet). PennLabs? Yes.

Perhaps a little ashamed of the fact, but I think it would be fair to say that I have always been easily annoyed with “management-like” readings (which is quite frequent given I attend a business school). I had my two reasons: 1) It seemed as if in an odd way, everything I read *I already knew *and 2) I didn’t think management could be “learned” — it comes with experience, and innate intuition. Those that are more perceptive might find it comes naturally, and well those that are less so might have to stumble over a few extra hurdles. But, two incidents this winter break changed my view of the “fluffy” stuff, as it is so often called, beginning with Sheryl Sandberg’s Lean In.

Though incredibly fond of Sheryl Sandberg, I was skeptical of her book at first. The turning point for me in the book came when she describes the differences between how men and women take praise. I know that if I am to congratulate one of my girl friends on their accomplishments, 9 out of 10 times I can be sure of them to rebut and instead attribute their success to some external factor like “luck” or “a generous curve.” The other 1 out of 10 times is a short “thanks” followed by reciprocal praise of one of my own accomplishments. But, compliment a guy friend similarly, and I generally expect a confident response along the lines of “I better do well. I worked so dang hard on that.”

It dawned on me that up until the moment Sheryl Sandberg literally put this problem in front of my face in black and white (size 10, Garamond font I think?), I may have subconsciously knew this was happening, but had never truly *recognized *it. In fact, as Sandberg points out in the book, I had actually internalized these actions as a societal norm and became a perpetrator myself! If I complimented a girl on a good grade and she replied along the lines of “Thanks, I feel like my work paid off ” I probably would have even thought “wow, how cocky.” While literature on organizational behavior may at times appear to be “common sense”, we need an extra push from others to externalize the common sense — hence, we borrow upon others’ incredible insights and experience through_ reading_to reveal to us something once hidden.

The second incident occurred on my way back to Penn. I happened to be on the same flight as Josh Doman, one of the co-directors previously described. We are in the same management class together this semester, and neither of us had done the assigned readings yet. We both planned to do it on the plane.

I fell asleep.

Josh didn’t.

Immediately coming off the plane, he launched into a passionate rant on how the readings had inspired him to entirely question the sustainability of PennLabs: What were our core competencies? How are we sourcing new ideas? How do we go from innovation to commercialization? What kind of culture are we perpetrating?

Standing there half-awake watching the baggage claim conveyor belt go round-and-round with Josh buzzing beside me, I realized that there was no way I could deny the teachability of management. Just four hours previously, those readings had only been downloaded pdfs, homework to be done. Four hours later, they came to life and became Josh’s source of attack to question the entire structure of an organization that he had worked endlessly to bring back to life.

As students of management, our job is to find the application. The value of the readings isn’t in the text itself, but how they can be drawn away from the pages to provide a framework for making decisions in the real-world — it’s this exact intangibility that causes us to term management as “fluffy.” Akin to studying history or understanding chess combinations, I can see studying management as a form of what I consider situational training.

By studying others’ experiences and becoming cognizant of certain response patterns, you can create a competitive advantage for yourself from the crowd when similar problems arise.

So yes, the fluffy stuff is important to learn.

Moving forward —

Since that plane ride, Josh has completely rethought the organization of Labs. He and Tiffany Chang (the other co-director!) together have began implementing significant structural changes to Labs.

Starting this semester, Labs will consist of a Board of Directors with 6 seats, made up of two co-directors and directors of internal, external, finance, and marketing. Though initially the four director positions will be filled by the to-be dissolved BD team, in the future, those positions will go to internal technical designers or product developers. Such a vertical and promotional structure is to encourage developers to take on more leadership and responsibility in hopes of laying the foundation for a sustainable management culture where decision-making didn’t fall entirely on the co-directors.

Teams themselves will no longer be strictly organized around products, but rather functionally, with a back-end API team and a team of designers. This structure allows for two meaningful improvements: 1) In flexibility — members will be able to work on a diverse array of projects and interact with different people, increasing club cohesiveness and culture 2) In efficiency —many projects use similar API’s and design logos so a centralized system of API development and design works to eliminate repetitive work.

In 2014, Facebook changed its motto from “Move Fast and Break Things” to “Move Fast with Stable Infra(structure)” (A quick Google search will reveal why ‘structure’ is in parenthesis). One could say we are undergoing a similar change. Though Zuckerberg used infrastructure to describe the stability and “bug-free-ness” of code, in the context of Labs, I like to think of infrastructure as *organizational *infrastructure. We are rebuilding — to prevent against another sudden collapse and so that we are officially ready to take on more quantity and complexity, in terms of both projects and people.

We joke around nostalgically that we’ve gone “corporate” but the truth is no organization wanting to grow stays a small, flat structure of people forever. The idealistic notion of tech groups as being made up of a few geeky, chill friends coding for fun must give way to some notion of a corporation structure at some point.

Though it will most likely be messy this next year since we are clearly no experts in growing an organization, or even running one for that matter, I am excited for the changes to come. And so should the Penn community. A more efficient Labs only means better and more services for students.

On another note …

This. Scene. Was. ICONIC. Look at that fluffy unicorn. (Multiple puns intended?) Disclaimer: this post is merely a reflection of thoughts from my 19-year old self. I have no intention nor the expertise to impose my perspectives on anyone.

*photo credits: _[http://www.managers.org.uk/insights/news/2017/june/a-management-manifesto-for-the-uk-fixing-the-84bn-productivity-gap_](http://www.managers.org.uk/insights/news/2017/june/a-management-manifesto-for-the-uk-fixing-the-84bn-productivity-gap)

The Problem with Problems and what Penn Labs is all About

Thu, 02 Nov 2017 00:00:00 GMT

I don’t know how often everyone here cooks but think about what happens when you pour oil into a pan. Due to a stubborn property of gravity, there’s always that extra drop that flows down the side of the container. At my house, we actually always keep a designated paper towel next to the oil jar solely for the purpose of catching this drip.

You’re probably wondering what this inconsequential concern has to do with anything — but it’s the mindset that I want to note. Before I pointed it out, had you ever considered this dripping as a problem at all? Maybe you’ve never even noticed it.

**Failure to recognize problems is what inhibits society **— not the problems inherently themselves.

Not recognizing problems is called complacency. Seeing a problem and choosing to ignore is called laziness. Both are equally detrimental.

Innovation is at the same time both the most jaded and the most ambiguous term in society today. We listen to TED Talks to learn from innovators; we use high tech gadgets to better innovate; we are put into diverse work groups to promote innovation— but what is it, really?

“Innovation simply put, is the child of problem and solution.”

Imagine if everyone, at any given moment, was racking their brains for ways to solve some sort of a problem. At a world population of 7.6 billion, that’s a whole lot of innovation.

Nowadays, we either view problem solving as this one-time achievement (hence the all-too-familiar “tell me about a time you solved a problem” interview question), or as some quantifiable skill. So much so that companies explicitly list it in their job postings, along with “teamwork”, “hardworking” and the other plethora of traits sure to distinguish the most unique applicants. Rather, problem solving is just a **constant** drive for improvement.

In fact, it has been proven time and again that the difference between the highly successful and the average population is in nothing other than what what they think about. There’s a reason that people like Steve Jobs and Mark Zuckerberg have multiple pairs of the same shirts, pants, shoes — it’s so they can maximize the time they devote to thinking about improving their work and not on trivial matters like “what should I wear today?”

That’s what drew me to be a part of PennLabs — we’re really just a problem solving organization dedicated to innovate and improve student life at Penn. Sitting in our weekly work meetings, you hear discussions from “is this really a problem that students struggle with?” to “what segment of the student population will even find this product useful?” The problems we try to tackle range from housing to dining to studying issues. Some resolutions to date:

Problem: students carrying their laundry up three floors only to find all the machines are in use. Solution:collect real-time laundry machine usage data and display it in Penn Mobile.

Problem: students want information on class and professor difficulty to make better course selection decisions. *Solution: *aggregate course and professor reviews on Penn Course Review.

*Problem: *students struggle to research and reach out to all possible funding opportunities on campus for their club or activity. *Solution: *a one-stop tool that sends funding requests to multiple sources at once through The Common Funding Application.

These are just a select few of the many problems that we at Labs ponder over day and night, and what drives them to build. It’s an obsession for solving the overlooked inefficiencies manifested in campus life, a passion for finding ways to make their friends’ time at Penn more enjoyable, and an overarching desire to bring Penn closer together as a community.

For those on campus and unaware that the services I listed above were available, take a minute to check out some of the cool solutions that Labs has developed. Download PennMobile from the AppStore to start exploring its features. Follow us on Facebook and Instagram for product updates. Follow us here to read more technological musings tangentially related to what we’re working on at Labs. And if you have any ideas of your own, feel free to suggest them to us at any point. Just as there are no dumb questions, there are no dumb innovations.

For example, don’t read too much into my narcissism here, but I would like to point out that the “inconsequential” oil drip problem we dismissed earlier now has an entire market dedicated to it. Isn’t pouring olive oil out of something like this the new bougie thing to do? Tablecraft H9085 Olive Oil Dispenser 8 oz, available at Amazon.com As a matter of fact, search some variation of “no drip spout” on Amazon and you will find a wide array designs, sizes, shapes of bottle spouts all dedicated to getting rid of the dripping. Clearly this problem extends further than a mere personal pet peeve.

But hey, look at the number of innovations it led to.

“**Innovation** comes from people meeting up in the hallways or calling each other at 10:30 at night with a **new idea**, or because they realized something that shoots holes in how we’ve been thinking about a **problem**.” ~ Steve Jobs