Implement the visual theme and design changes you developed with Evelyn
Resources:
You'll mostly be using a combination of MUI's sx prop, styled(), and useTheme() to implement different components. I'll give some recommendations below
react-responsive-spritesheet documentation (linked in Wiki)
Sprite packages from last deliv (if anything needs to be purchased just ask!)
Workflow for the deliv (from 3/3 conversation with Evelyn)
As of SWE sync 3/3, it looks like you're basically done with the refactoring (just modals and tables left). The "refactoring" of modals and tables (which we agreed to use styled() on) can be baked into your actual implementation of the visual framework in this deliv; basically, just use styled() or useTheme() to style modal and table components when you're implementing.
For this week, you should spend more time on thinking through the visual design with Evelyn (see answering the questions posed in the previous deliv) since that's something we're a bit behind on. Below I'll list some initial gamification features that are fairly simple/obvious to implement that you can work on concurrently with your design work. I'll also list the order in which I think you should address various design-related questions with Evelyn.
Initial gamification features (can start now)
Loading indicators
Right now, our app doesn't display any loading indicators while fetching data from Firebase. We should add these in wherever the user would potentially have to "wait" for some loading to occur.
MUI has loading spinners you can use for an initial start, but a more gamified approach would be a sprite animation! For a loading indicator I think you can render an animated version of the player's current character (which is a running animation), see items.tsx and avatar.tsx for examples on how the current avatar is rendered. Make sure to conditionally check for the player's avatar outfit existing (properties on the player object), and if any are invalid then return the standard loading indicator instead.
Home page
Our home page is rather bare bones and uninformative right now. We'll probably end up expanding on it more through the design process, but for the time being you could remove the blue background behind "Welcome", change the Welcome message/create classroom button/join classroom button to be a little more descriptive, and maybe render a big sprite of your choice on the homepage.
Design questions in order of priority
Take this ordering with a grain of salt and feel free to add/remove items, since I'm limited in my design experience.
The "context" for the gamified experience I'm imagining for Questable is: A medieval setting, where students in the class are adventurers in a guild led by a guildmaster (teacher). The teacher assigns quests (tasks and repeatables) like defeating monsters or gathering resources that can be completed by the students to earn gold (money) that can be used to purchase equipment (outfits) in the town market (shop).
What sprites to use and where?
The biggest part of Questable's gamification is currently its use of video-game-like sprites throughout the app. What sprites should we use (and where) to implement the gamified experience of the app? Initial thoughts/suggestions:
Randomized sprites to represent core workflow elements
"Monsters" like goblins and slimes to represent tasks/repeatables as enemies to defeat, can be displayed alongside the task information as decoration
Treasure chests, gold, etc. to represent task rewards
Sprites as appropriate replacements for UI iconography/elements
Indicators for how much money a player has
Buttons for completing a task, purchasing/equipping items, other functions that can be related to the imagined setting
Page background?
I think having some sort of backdrop to the app (rather than a white screen) could help establish the setting better. What sort of backdrop might we use? A PNG that we find online, or something "tiled"/constructed from sprites (see our spritepacks)? With any non-white background we would also have to make sure it agrees visually with our frontend components.
Typography and colors
What color and fonts to use for the app. It's okay to stick with the native MUI fonts, but I think here is another opportunity to make them more "gamified" while still being readable.
Atomic appearance of MUI elements
MUI already gives us prestyled components for buttons, cards, tables, modals, etc. that look fine, but perhaps there is some room for modulation here to make the UI look cleaner/more polished. The changes you decide to make here will probably depend on the decisions you make in the preceding questions, and they will be quite subtle so I have the least specific advice to give here. Think about CSS changes/overrides you could make the components/MUI elements you previously refactored.
Frontend:
Component redesigns
If parts of the redesign call for changing how a core element looks (i.e. typography, colors, buttons, tables) I would use useTheme() to make global overrides to these components.
For styling compnents you have already extracted into shared code with React composition, it's probably fine to just use the inline sx prop to do your styling, since these styling changes don't need to be carried elsewhere
I would use styled() for situations such as:
Needing different designs for the same component (i.e. button), but still wanting access to the native MUI variants of that component (meaning you can't just do a theme override)
Multiple repeated components within the same file that need the same styling and are unique from other components in the app (again, useTheme() is the easier solution for changing how a specific component looks globally)
Sprites
If you are using a sprite as a static UI element that will never change: I recommend just making your own PNG (a cropped copy of the spritesheet) and importing that PNG.
If you are using a sprite which is animated or will change depending on the context of the app (ex: using a variety of different "monster" sprites to represent tasks), you'll have to use react-responsive-spritesheet.
At the time of writing, Questable uses react-responsive-spritesheet to traverse spritesheets and render both static/animated sprites. You can see our existing code for this in items.tsx.
To reduce your code reuse, I'd recommend adding a file in utils called sprites.tsx with functions that will render a sprite based on minimal input parameters. The render() function in items.tsx is a good example!
By the time you start adding in sprites, Itzel may be done with migration to react-pixi, which is a much more robust animation library, in which case the code to items.tsx will have changed. You can consult her if you need any guidance on using that package, and I'll update this deliv retroactively if need be. Edit 3/3/23 we will likely not be using react-pixi
Gamification: Implement visual design theme/framework
Overview:
Implement the visual theme and design changes you developed with Evelyn
Resources:
sxprop,styled(), anduseTheme()to implement different components. I'll give some recommendations belowsxpropstyled()componentsreact-responsive-spritesheetdocumentation (linked in Wiki)Workflow for the deliv (from 3/3 conversation with Evelyn)
As of SWE sync 3/3, it looks like you're basically done with the refactoring (just modals and tables left). The "refactoring" of modals and tables (which we agreed to use
styled()on) can be baked into your actual implementation of the visual framework in this deliv; basically, just usestyled()oruseTheme()to style modal and table components when you're implementing.For this week, you should spend more time on thinking through the visual design with Evelyn (see answering the questions posed in the previous deliv) since that's something we're a bit behind on. Below I'll list some initial gamification features that are fairly simple/obvious to implement that you can work on concurrently with your design work. I'll also list the order in which I think you should address various design-related questions with Evelyn.
Initial gamification features (can start now)
Loading indicators
Right now, our app doesn't display any loading indicators while fetching data from Firebase. We should add these in wherever the user would potentially have to "wait" for some loading to occur. MUI has loading spinners you can use for an initial start, but a more gamified approach would be a sprite animation! For a loading indicator I think you can render an animated version of the player's current character (which is a running animation), see
items.tsxandavatar.tsxfor examples on how the current avatar is rendered. Make sure to conditionally check for the player's avatar outfit existing (properties on theplayerobject), and if any are invalid then return the standard loading indicator instead.Home page
Our home page is rather bare bones and uninformative right now. We'll probably end up expanding on it more through the design process, but for the time being you could remove the blue background behind "Welcome", change the Welcome message/create classroom button/join classroom button to be a little more descriptive, and maybe render a big sprite of your choice on the homepage.
Design questions in order of priority
Take this ordering with a grain of salt and feel free to add/remove items, since I'm limited in my design experience.
The "context" for the gamified experience I'm imagining for Questable is: A medieval setting, where students in the class are adventurers in a guild led by a guildmaster (teacher). The teacher assigns quests (tasks and repeatables) like defeating monsters or gathering resources that can be completed by the students to earn gold (money) that can be used to purchase equipment (outfits) in the town market (shop).
What sprites to use and where?
The biggest part of Questable's gamification is currently its use of video-game-like sprites throughout the app. What sprites should we use (and where) to implement the gamified experience of the app? Initial thoughts/suggestions:
Page background?
I think having some sort of backdrop to the app (rather than a white screen) could help establish the setting better. What sort of backdrop might we use? A PNG that we find online, or something "tiled"/constructed from sprites (see our spritepacks)? With any non-white background we would also have to make sure it agrees visually with our frontend components.
Typography and colors
What color and fonts to use for the app. It's okay to stick with the native MUI fonts, but I think here is another opportunity to make them more "gamified" while still being readable.
Atomic appearance of MUI elements
MUI already gives us prestyled components for buttons, cards, tables, modals, etc. that look fine, but perhaps there is some room for modulation here to make the UI look cleaner/more polished. The changes you decide to make here will probably depend on the decisions you make in the preceding questions, and they will be quite subtle so I have the least specific advice to give here. Think about CSS changes/overrides you could make the components/MUI elements you previously refactored.
Frontend:
Component redesigns
useTheme()to make global overrides to these components.sxprop to do your styling, since these styling changes don't need to be carried elsewherestyled()for situations such as:useTheme()is the easier solution for changing how a specific component looks globally)Sprites
react-responsive-spritesheet.react-responsive-spritesheetto traverse spritesheets and render both static/animated sprites. You can see our existing code for this initems.tsx.sprites.tsxwith functions that will render a sprite based on minimal input parameters. Therender()function initems.tsxis a good example!By the time you start adding in sprites, Itzel may be done with migration toEdit 3/3/23 we will likely not be usingreact-pixi, which is a much more robust animation library, in which case the code toitems.tsxwill have changed. You can consult her if you need any guidance on using that package, and I'll update this deliv retroactively if need be.react-pixi