2. Overview
Media Backlog App
Finding items to watch based on user-supplied criteria
Available time, genre, show type, etc.
Being able to easily add items to backlog
View items in backlog
Tools Used and Why
Visual Studio, C#
IMDB API, MySQL
Upcoming internship
Development Process – consisting of sprints
First few consisted of independent items: API and database connection classes, GUI design, etc.
Remaining sprints focused on linking elements together
3. Initial Idea
So much to see, so little time
Lots of suggestions to keep track of
Optimal way of content consumption – dealing with awkward downtime
Solution to endlessly scrolling streaming apps
4. Searching for a Show
Initial Search
◦ Runtime and type
Advanced Search
◦ More options
Result Set
◦ Scrolling and marking as watched
5. Adding a Show to the Backlog
Info pulled from IMDB
Simple Search via title
◦ Up to 10 results
◦ Selection based on double click
7. UI Design
Design goals
“Lightweight” mobile app-esque
Responsive controls
Minimalist
Wilbert Galitz’s design philosophy and styles
Human action cycle
Goal Formation, execution of activities, evaluation of results
Short, but intuitive path from point A to point B
My experience with data entry and how that impacted this project
Feature creep
Minor details causing major slowdown
8. Challenges and Shortcomings
Compromises with UI elements - listview
Limited Testing
Cut Content – video games and books
Positive note: something to build from
Exercised what I’ve learned in my field, learned new things, and inspired me to improve even further
Project serves as a good base for further improvement
Editor's Notes
-This app has 2 primary functions: to keep track of shows and movies the user may be interested in and to suggest those items based on user supplied criteria – with the primary criteria being the amount of free time they have, but also other things such as genre, rating, director, and so on
-The user is also able to view and edit which items are in their backlog via a backlog view tab
-I wrote this app entirely using C# and Windows Forms, and made use of an API to access IMDB, the largest database of film and tv series on the internet, to supply information about the shows the user added to their backlog such as runtime, genres, summaries and more. To store their choices, I made use of a MySQL database.
-My reasoning for using these tools is partially due to prior experience with them, but mostly because my upcoming internship will be based around C#, dealing with data transferred via JSON, and various oracle corporation tools, including MySQL.
-My development process was consisted of sprints with varying tasks – the first few consisted of exploring ideas and setting up individual components such as database and API connections, and the remaining sprints primarily dealt with bringing everything together
-The initial idea stemmed from my friend group’s tendency to suggest movies and shows to each other, to a point where keeping track of everything gets difficult
-I also found myself with awkward stretches of downtime, whether it was between classes or between finishing homework and going to sleep, so I figured having something to optimize that downtime might be nice
-I also think there’s a common experience that’s plagued streaming apps since they’ve become popular, which is endlessly scrolling the streaming app and finding nothing – I don’t really think that’s necessarily a problem of content quality, but is instead one of overwhelming quantity and I feel like this app gives some direction
-First: free hour, up for anything
-Second: two and a half hours, and feeling like something action-y
-Third: using default option (no time constraint), from Ridley Scott
-Final: 3 hours and you want to watch something with your favorite actor, Ryan Gosling
Design Goals
-When brainstorming ideas for this project, the word I kept coming back to was “lightweight”, meaning that the app would be quick to pick up, find or add a show, and easy to quit – this was something I took in to account when building each part of the app and dictated when certain events happened, such as database connections, HTTP requests and so on
-I would’ve liked to have done some testing with friends to refine this app further, but due to COVID, I didn’t think that was a responsible choice
-This lightweight nature would probably be best served by a mobile app, but given my lack of experience in that area, I opted to go with a desktop app.
-I also wanted each control to have a clear purpose and be responsive, while not being overwhelming, so I tried to keep the UI as minimalist as possible – to achieve that goal, I tried to keep each control
-To do this, I tried to ensure every control would have some feedback to being selected or hovered over, whether it was a message appearing
When working on this project, I’d reference Wilbert Galitz’s “The Essential Guide to User Interface Design” whenever I felt I was unsure on something
One design philosophy he touches on is the Human Action Cycle . To sum it up, the Human Action Cycle consists of three phases: goal formation, execution of activities to achieve said goal, and evaluation of results
Given the relatively simple nature of the app, the user would ideally come into the app with their goal in mind: finding something to watch or something to add
The execution of the goal is where I put must of my energy when designing the app – the make it as easy as possible, the number of steps to achieve the goal must be
As I mentioned, I wanted the controls to feel responsive, which is vital to the evaluation of results
My current job involves property data entry via form entry. Since the app was in development when I was hired, I was able to see how the development process progressed and I saw a fair amount of feature creep with seemingly small features being added that ended up making the end user experience feel somewhat clunky. To address this issue in my development process, I simply didn’t add any other features and spent a good deal of time from the outset outlining what I felt the app needed vs. what it didn’t.