Live site: http://habitualbedemo.com
2-min technical walkthrough of backend: https://www.youtube.com/watch?v=DQJ86Dg0IM8
Introduction
User Research and Insights
Investigation Procedures
Data sources
Key Insights
Limitations
Ideation and Prototyping
My Design Process
System Design Decisions
Tech Stack Decisions
Challenges + Blockers
Final Solution and Implementation
Conclusion and Reflections
Introduction
The research question/problem is related to the lack of accessibility to cultural museums and art collections for people interested in exploring Black museums and art collections. The proposed solution is a web application, named HabitualBe, which aims to increase visibility and accessibility to these vital cultural institutions through a digital platform.
The objective of the solution is to enable art enthusiasts to effortlessly discover and explore Black museums, art collections, and audio guide tours online.
This project was done as a part of my completion of a sponsored 3-month HackBright Women's Fullstack Software Engineering Fellowship. Despite being the sole contributor, I managed to finish it in just a few weeks, thanks to the guidance and support of my advisors. My degree in Digital Media Innovation, combined with my short-lived experiences as a Graphic Design and then as a Computer Science major, Google, and my network of supportive women engineers from HackBright, also contributed to my success.
User research and insights
Investigation Procedures
I used mixed methods to address a single research question:
How can we address the issue of limited accessibility to cultural museums and art collections for art-curious individuals and enthusiasts?
I used a correlational research design to examine the relationship between major museums such as the MoMA in NYC, the National Museum of African American History and Culture in D.C. (aka Blacksonian), Brooklyn Museum and the Museum of Fine Arts, Houston, and their prevalence of Black art.
Survey research design is a quantitative method I used to gather information from my local museums via phone interviews. This assessed attitudes, beliefs, behaviors, and experiences of museum goers and their audio guide experience.
Woman peers at photo collage in MFAH.
I used a case study research design to study various museum organizations in-depth to gain insight into the bustling digital visits and audio guide experiences in museums and the spike in digital museum visits during peak COVID-19 pandemic. (Notable ones include: ex1, ex2, ex3)
Using an ethnographic research design allowed me to immerse myself in my culture even more and to gain a deeper understanding of Black-American's and African beliefs, values, and behaviors in regards to art.
Data sources
My web app boasts a robust collection of data with 10 distinct resources, including collections, collection sounds, related sounds, art objects, users, museums, and user-specific favorites for art, museums, collections, and audio guide tours.
The data sources for this project were open source museum documents courtesy of the Institute of Museum and Library Services, OpenGLAM, museum websites, various museum's Github data dumps, personal museum frequents, museum personnel, and case studies (as mentioned before).
I used Python programming language to clean and sort the open source museum spreadsheet data and insert it into my database so that museum location, website and geographical info could be a readily available resource my user requests from the app when looking for museums. The OpenGLAM legal and technical framework many of these museums use allows for the digitization, preservation, and dissemination of cultural heritage materials, such as art, historical documents, and artifacts, making them available to a wider audience.
The museum website data allowed for some rich categories to be implemented into the apps 'Art Object' resources like photographs, prints, ceramics, metalwork, drawings, pastels, watercolors, jewelry & adornments, painting, costume & accessories, sculpture, and furniture.
The data dumps provided by museum's on their Github pages proved useful when later in the design process it was time to publish real resources and not just dummy info and placeholders used for testing.
The personal museum frequents, chats with museum personnel and docents were merely a cherry on top when researching for this app.
Key Insights 🔑
While cleaning data sets, I noticed that many museums and cultural heritage sites suffered financially during the COVID-19 pandemic. The lack of funding resulted in disconnected phone numbers and neglected facilities. For more information on efforts to address this, check out this NYT article. Additionally, I found that visitors have different experiences depending on whether they visit museums alone, with family, or for business.
Limitations
To mitigate limitations and biases, I designed the study with the project's time constraints in mind. I ensured sample representation of the product's target audience and utilized reliable and valid tools to achieve intended outcomes for industry impact and art education user benefits.
These limitations were not complete hindrances and allowed me to make reasonable assumptions. It helps that I am also apart of MFAH's African-American Art Advisory Association and a museum frequenter myself. My monthly museum and cultural art event frequents are often recorded in an ongoing Notion doc. I'm at about 30 U.S. museums!
As a result of data mining and research, users can now enjoy a plethora of features, such as browsing a comprehensive list of audio guide tours, collections, art, and over 70 Black museums, favoriting their preferred content, accessing related materials, and seamlessly logging in/out or registering.
Ideation and prototyping
I collaborated alongside my cohortmates to test features and usability and completed this solo project using an agile approach that involved two sprints. They came from all walks of life, educational background and industries and this provided me access to diverse SME's.
My design process
My design process is 9-steps, its thorough, its necessary and proven to give me results.
My design process is a mix of the physical product design process from my time minoring in Industrial Design, Stanford's d.school design process from my time coaching at their Design The Future summer camp, and the software development lifecycle (SDLC).
Define > Generate Concepts > Research > Design > Implement > Test > Evaluate > Present > Ongoing Optimization
As a web developer, I start by really getting to grips with the problem I'm trying to solve. I want to make sure I fully understand what needs to be done before I dive in. Then, I like to look at some of the best museum websites out there to see what they're doing right and to get some inspiration for my own design.
After that, I get down to the nitty-gritty of figuring out the best tech solution for the job. This means doing a ton of research and making sure that whatever solution I come up with is the best one possible. Once I have a solid concept, I start putting everything together into a cohesive design that looks good and works well. I was able to draw upon my creative background for this and take it further than what was expected of me in this fellowship.
Taking a hands-on approach, I iteratively designed a comprehensive solution, complete with a thoughtfully crafted design system for the site. As mentioned in the data section, I prototyping with fake data during this stage to lay the initial groundwork and constructed the skeleton of the application, testing each step of the way.
A Design System is “a regularly interacting or interdependent group of items forming an integrated whole”. In other words, a Design System is something that connects design and code to make a product. -Oscar Gonzalez
As any good problem solver would, I evaluated my tests, and made adjustments to further refine the solution. Finally, I presented the web app to my peers in the art space, as well as to software engineering and PD SMEs, obtaining valuable user feedback through a series of walkthroughs. Armed with this input, I inserted real data into the web app, and was pleased to see the final product meet and exceed expectations.
System design decisions
I began by creating a diagram of what resources related to each other and how and a database schema to figure out which resources I would need. To enhance the user experience, I also modeled an initial user flow, which I refined after conducting several studies.
Through this iterative process, I was able to improve the user's click-through experience, and ensure I had just enough data to flesh out a minimum viable product in order to prove the concept of the app.
Tech stack decisions
Flask, SqlAlchemy, Python, Jinja, PostgreSQL, and Psycopg2 are all technologies that are commonly used in the back-end development of web applications. These tools are used to build the server-side of the application, which includes processing and handling user requests, data storage, and data retrieval.
There are many different technologies available to use when creating a data-heavy mobile and web app for museum and audio guide tour discovery. However, in my opinion, the combination of Flask, SqlAlchemy, Python, Jinja, PostgreSQL, Git, Github, Psycopg2, HTML, Vanilla Javascript, CSS, and Bootstrap5 proved to be the best choice.
BACKEND:
Flask is a lightweight and flexible Python framework for building web apps with strong community support. SqlAlchemy simplifies complex SQL queries and integrates well with Python. Python has extensive libraries for handling data, making it ideal for server-side development. Jinja is a Python-based templating engine for rendering HTML documents. PostgreSQL is an open-source database management system that is scalable and ideal for data-heavy apps. Git and Github are essential for managing code changes and collaborating with other developers. Psycopg2 simplifies complex SQL queries for Python and PostgreSQL integration.
FRONT END:
HTML, Vanilla Javascript, CSS, and Bootstrap5 are essential for front-end development and to do things like build the client-side of the application, create the structure and content of web pages, and style them.
For example, Vanilla Javascript is used to add interactivity and dynamic behavior to web pages. I used it throughout my site for the user experience and even in the backend (the database and resource management layer).
The combination of this fullstack web development tech stack helped me engineer a robust and data-heavy mobile and web app for museum and audio guide tour discovery. These technologies are highly scalable, efficient, and provide an excellent developer experience, making them the perfect choice.
A 2-min technical walkthrough of my web app design process. A low-level description of tech specs, features and challenges.
Challenges + Blockers
CHALLENGE #1
One of the major blockers I was able to overcome happened in the refinement stage. My users were unable to create, delete, or update their favorite museum, collection, audio, and art on the app.
In my code, I used the JavaScript language to send "requests" (think of these as little favors the browser wants the web app to complete successfully upon mouse-click) to my server-side code (aka the "backend" because it happens in the database part of my app that only I see).
It involves setting up an API endpoint (this is like a special door that the favors can go through to get to the backend part of the app) on the server (my server file that I wrote in Python that is) that your client-side code (the "frontend" in-browser activity) can send requests to, using a protocol such as HTTP.
Upon investigation and consulting with others, I discovered that the JavaScript API setup was not correctly committing the favoriting action to the database for logged-in users. However, with persistence, I was able to properly configure the button and persist the in-browser favoriting action to the backend using AJAX requests. This allowed the web page to update asynchronously without the need for refreshing, which improved the user experience.
CHALLENGE #2
I faced a challenge related to data retrieval and linking the different resources in my 10-table (data tables that hold user info, art info, collection info etc!) full-stack web app. To overcome this issue, I used object-relational mapping provided by SQLAlchemy to create relationships between the data using their special SQLAlchemy relationship variables.
After querying the data, I had to loop through a significant amount of content to display it on the client-side. While relating five main entities, I realized the complexity and breadth of my ambitious 10-table database. This reinforced my need for multiple join and associative tables in my model.
Overall, I used PostgreSQL, SQLAlchemy, and Python with Flask to create a complex database schema and a full-stack web application. Using ORM simplified the data retrieval and linking process for me.
Final solution and implementation
And there you have it, I've created a full-stack web and mobile app that addresses the issue of the lack of accessibility to Black museums and art collections. The platform allows art enthusiasts like me to easily discover and explore Black museums and art collections online, which promotes greater visibility and access to these important cultural institutions.
To balance user needs, I have kept my features to a minimum viable product, focusing on the most essential features that meet the user's needs. At the same time, I have taken into account the research question and goals, such as promoting greater diversity and inclusivity within the arts community, and technical constraints, using Flask, SqlAlchemy, Python, Jinja, PostgreSQL, Git, Github, Psycopg2, HTML, Vanilla Javascript, CSS, and Bootstrap5 to create a robust and scalable platform.
Conclusion and reflections
If I had a longer time table, here are things I'd add to my MVP: If I were to make my app more accessible, I might consider implementing ARIA (Accessible Rich Internet Applications) guidelines. This could potentially ensure that users with disabilities have an equal opportunity to experience art and culture by allowing them to fully utilize and interact with the app.
One hypothetical feature I could add to enhance user experience is populating audio guides based on geo-fencing using the user's location. This might provide users with personalized audio guides that are specific to the artwork or exhibit they are viewing.
Another hypothetical idea could be to leverage more open source museum and related audio information from the web and centralize it for broader art discovery. This might allow users to access a wider range of audio guides and information, making the app a more valuable resource for art lovers.
To protect user data and prevent security breaches, I might consider using techniques such as peppering, salting, and hashing passwords. This could potentially ensure that user data is securely stored and protected from hackers and other security threats.
Lastly, I might consider having access to an audio guide standardization proposal and mockup to ensure that the app's audio guides are consistent in terms of quality, format, and delivery. This could potentially provide users with a consistent and reliable experience.
In conclusion, my product demo addresses my problem statement and research question by providing a proof of concept product that promotes greater visibility and access to over 70 Black cultural institutions as well as audio guides. This not only benefits art enthusiasts seeking to broaden their knowledge and appreciation of Black art and culture, but also helps to promote greater diversity and inclusivity within the arts community as a whole. By creating a simple and effective platform, I am contributing to the promotion of greater accessibility, awareness, and appreciation for Black art and culture.
Links / Sources
Live site: http://habitualbedemo.com
2-min technical walkthrough of backend: https://www.youtube.com/watch?v=DQJ86Dg0IM8
