chris
1 month ago
parent
17da96140c
commit
99d78c0f41
@ -1,13 +1,150 @@
|
||||
# Style your bank app
|
||||
# Style Your Bank App with Modern CSS
|
||||
|
||||
## Project Overview
|
||||
|
||||
Transform your functional banking application into a visually appealing, professional-looking web app using modern CSS techniques. You'll create a cohesive design system that enhances user experience while maintaining accessibility and responsive design principles.
|
||||
|
||||
This assignment challenges you to apply contemporary web design patterns, implement a consistent visual identity, and create an interface that users will find both attractive and intuitive to navigate.
|
||||
|
||||
## Instructions
|
||||
|
||||
Create a new `styles.css` file and add a link to it in your current `index.html` file. In the CSS file you just created add some styling to make the *Login* and *Dashboard* page looks nice and tidy. Try to create a color theme to give your app its own branding.
|
||||
### Step 1: Setup Your Stylesheet
|
||||
|
||||
**Create your CSS foundation:**
|
||||
|
||||
1. **Create** a new file called `styles.css` in your project root
|
||||
2. **Link** the stylesheet in your `index.html` file:
|
||||
```html
|
||||
<link rel="stylesheet" href="styles.css">
|
||||
```
|
||||
3. **Start** with CSS reset and modern defaults:
|
||||
```css
|
||||
/* Modern CSS reset and base styles */
|
||||
* {
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
box-sizing: border-box;
|
||||
}
|
||||
|
||||
body {
|
||||
font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;
|
||||
line-height: 1.6;
|
||||
color: #333;
|
||||
}
|
||||
```
|
||||
|
||||
### Step 2: Design System Requirements
|
||||
|
||||
**Implement these essential design elements:**
|
||||
|
||||
#### Color Palette
|
||||
- **Primary color**: Choose a professional color for buttons and highlights
|
||||
- **Secondary color**: Complementary color for accents and secondary actions
|
||||
- **Neutral colors**: Grays for text, borders, and backgrounds
|
||||
- **Success/Error colors**: Green for success states, red for errors
|
||||
|
||||
#### Typography
|
||||
- **Heading hierarchy**: Clear distinction between H1, H2, and H3 elements
|
||||
- **Body text**: Readable font size (minimum 16px) and appropriate line height
|
||||
- **Form labels**: Clear, accessible text styling
|
||||
|
||||
#### Layout and Spacing
|
||||
- **Consistent spacing**: Use a spacing scale (8px, 16px, 24px, 32px)
|
||||
- **Grid system**: Organized layout for forms and content sections
|
||||
- **Responsive design**: Mobile-first approach with breakpoints
|
||||
|
||||
### Step 3: Component Styling
|
||||
|
||||
**Style these specific components:**
|
||||
|
||||
#### Forms
|
||||
- **Input fields**: Professional borders, focus states, and validation styling
|
||||
- **Buttons**: Hover effects, disabled states, and loading indicators
|
||||
- **Labels**: Clear positioning and required field indicators
|
||||
- **Error messages**: Visible error styling and helpful messaging
|
||||
|
||||
#### Navigation
|
||||
- **Header**: Clean, branded navigation area
|
||||
- **Links**: Clear hover states and active indicators
|
||||
- **Logo/Title**: Distinctive branding element
|
||||
|
||||
#### Content Areas
|
||||
- **Sections**: Clear visual separation between different areas
|
||||
- **Cards**: If using card-based layouts, include shadows and borders
|
||||
- **Backgrounds**: Appropriate use of white space and subtle backgrounds
|
||||
|
||||
### Step 4: Enhanced Features (Optional)
|
||||
|
||||
**Consider implementing these advanced features:**
|
||||
- **Dark mode**: Toggle between light and dark themes
|
||||
- **Animations**: Subtle transitions and micro-interactions
|
||||
- **Loading states**: Visual feedback during form submissions
|
||||
- **Responsive images**: Optimized images for different screen sizes
|
||||
|
||||
## Design Inspiration
|
||||
|
||||
**Modern banking app characteristics:**
|
||||
- **Clean, minimal design** with plenty of white space
|
||||
- **Professional color schemes** (blues, greens, or sophisticated neutrals)
|
||||
- **Clear visual hierarchy** with prominent call-to-action buttons
|
||||
- **Accessible contrast ratios** meeting WCAG guidelines
|
||||
- **Mobile-responsive layouts** that work on all devices
|
||||
|
||||
## Technical Requirements
|
||||
|
||||
### CSS Organization
|
||||
```css
|
||||
/* 1. CSS Custom Properties (Variables) */
|
||||
:root {
|
||||
--primary-color: #007bff;
|
||||
--secondary-color: #6c757d;
|
||||
/* Add more variables */
|
||||
}
|
||||
|
||||
/* 2. Base Styles */
|
||||
/* Reset, typography, general elements */
|
||||
|
||||
/* 3. Layout */
|
||||
/* Grid, flexbox, positioning */
|
||||
|
||||
/* 4. Components */
|
||||
/* Forms, buttons, cards */
|
||||
|
||||
/* 5. Utilities */
|
||||
/* Helper classes, responsive utilities */
|
||||
|
||||
/* 6. Media Queries */
|
||||
/* Responsive breakpoints */
|
||||
```
|
||||
|
||||
### Accessibility Requirements
|
||||
- **Color contrast**: Ensure at least 4.5:1 ratio for normal text
|
||||
- **Focus indicators**: Visible focus states for keyboard navigation
|
||||
- **Form labels**: Properly associated with inputs
|
||||
- **Responsive design**: Usable on screens from 320px to 1920px wide
|
||||
|
||||
## Evaluation Rubric
|
||||
|
||||
| Criteria | Exemplary (A) | Proficient (B) | Developing (C) | Needs Improvement (F) |
|
||||
|----------|---------------|----------------|----------------|----------------------|
|
||||
| **Design System** | Implements comprehensive design system with consistent colors, typography, and spacing throughout | Uses consistent styling with clear design patterns and good visual hierarchy | Basic styling applied with some consistency issues or missing design elements | Minimal styling with inconsistent or conflicting design choices |
|
||||
| **User Experience** | Creates intuitive, professional interface with excellent usability and visual appeal | Provides good user experience with clear navigation and readable content | Basic usability with some UX improvements needed | Poor usability, difficult to navigate or read |
|
||||
| **Technical Implementation** | Uses modern CSS techniques, organized code structure, and follows best practices | Implements CSS effectively with good organization and appropriate techniques | CSS works correctly but may lack organization or modern approaches | Poor CSS implementation with technical issues or browser compatibility problems |
|
||||
| **Responsive Design** | Fully responsive design that works beautifully across all device sizes | Good responsive behavior with minor issues on some screen sizes | Basic responsive implementation with some layout issues | Not responsive or significant problems on mobile devices |
|
||||
| **Accessibility** | Meets WCAG guidelines with excellent keyboard navigation and screen reader support | Good accessibility practices with proper contrast and focus indicators | Basic accessibility considerations with some missing elements | Poor accessibility, difficult for users with disabilities |
|
||||
|
||||
## Submission Guidelines
|
||||
|
||||
> Tip: you can modify the HTML and add new elements and classes if needed.
|
||||
**Include in your submission:**
|
||||
- **styles.css**: Your complete stylesheet
|
||||
- **Updated HTML**: Any HTML modifications you made
|
||||
- **Screenshots**: Images showing your design on desktop and mobile
|
||||
- **README**: Brief description of your design choices and color palette
|
||||
|
||||
## Rubric
|
||||
**Bonus points for:**
|
||||
- **CSS custom properties** for maintainable theming
|
||||
- **Advanced CSS features** like Grid, Flexbox, or CSS animations
|
||||
- **Performance considerations** like optimized CSS and minimal file size
|
||||
- **Cross-browser testing** ensuring compatibility across different browsers
|
||||
|
||||
| Criteria | Exemplary | Adequate | Needs Improvement |
|
||||
| -------- | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------- |
|
||||
| | All pages looks clean and readable, with a consistent color theme and and the different sections standing out properly. | Pages are styled but without a theme or with sections not clearly delimitated. | Pages lack styling, the sections looks disorganized and the information is difficult to read. |
|
||||
> 💡 **Pro Tip**: Start with mobile design first, then enhance for larger screens. This mobile-first approach ensures your app works well on all devices and follows modern web development best practices.
|
||||
@ -1,15 +1,128 @@
|
||||
# Refactor and comment your code
|
||||
# Code Refactoring and Documentation Assignment
|
||||
|
||||
## Learning Objectives
|
||||
|
||||
By completing this assignment, you will practice essential software development skills that professional developers use daily. You'll learn to organize code for maintainability, reduce duplication through abstraction, and document your work for future developers (including yourself!).
|
||||
|
||||
Clean, well-documented code is crucial for real-world web development projects where multiple developers collaborate and codebases evolve over time.
|
||||
|
||||
## Assignment Overview
|
||||
|
||||
Your banking app's `app.js` file has grown significantly with login, registration, and dashboard functionality. It's time to refactor this code using professional development practices to improve readability, maintainability, and reduce duplication.
|
||||
|
||||
## Instructions
|
||||
|
||||
As your codebase grows, it's important to refactor your code frequently to keep it readable and maintainable over time. Add comments and refactor your `app.js` to improve the code quality:
|
||||
Transform your current `app.js` code by implementing these three core refactoring techniques:
|
||||
|
||||
### 1. Extract Configuration Constants
|
||||
|
||||
**Task**: Create a configuration section at the top of your file with reusable constants.
|
||||
|
||||
**Implementation guidance:**
|
||||
- Extract the server API base URL (currently hardcoded in multiple places)
|
||||
- Create constants for error messages that appear in multiple functions
|
||||
- Consider extracting route paths and element IDs that are used repeatedly
|
||||
|
||||
**Example structure:**
|
||||
```javascript
|
||||
// Configuration constants
|
||||
const API_BASE_URL = 'http://localhost:5000/api';
|
||||
const ROUTES = {
|
||||
LOGIN: '/login',
|
||||
DASHBOARD: '/dashboard'
|
||||
};
|
||||
```
|
||||
|
||||
### 2. Create a Unified Request Function
|
||||
|
||||
**Task**: Build a reusable `sendRequest()` function that eliminates duplicate code between `createAccount()` and `getAccount()`.
|
||||
|
||||
**Requirements:**
|
||||
- Handle both GET and POST requests
|
||||
- Include proper error handling
|
||||
- Support different URL endpoints
|
||||
- Accept optional request body data
|
||||
|
||||
**Function signature guidance:**
|
||||
```javascript
|
||||
async function sendRequest(endpoint, method = 'GET', data = null) {
|
||||
// Your implementation here
|
||||
}
|
||||
```
|
||||
|
||||
### 3. Add Professional Code Documentation
|
||||
|
||||
**Task**: Document your code with clear, helpful comments that explain the "why" behind your logic.
|
||||
|
||||
**Documentation standards:**
|
||||
- Add function documentation explaining purpose, parameters, and return values
|
||||
- Include inline comments for complex logic or business rules
|
||||
- Group related functions together with section headers
|
||||
- Explain any non-obvious code patterns or browser-specific workarounds
|
||||
|
||||
**Example documentation style:**
|
||||
```javascript
|
||||
/**
|
||||
* Authenticates user and redirects to dashboard
|
||||
* @param {Event} event - Form submission event
|
||||
* @returns {Promise<void>} - Resolves when login process completes
|
||||
*/
|
||||
async function login(event) {
|
||||
// Prevent default form submission to handle with JavaScript
|
||||
event.preventDefault();
|
||||
|
||||
// Your implementation...
|
||||
}
|
||||
```
|
||||
|
||||
## Success Criteria
|
||||
|
||||
Your refactored code should demonstrate these professional development practices:
|
||||
|
||||
### Exemplary Implementation
|
||||
- ✅ **Constants**: All magic strings and URLs are extracted into clearly named constants
|
||||
- ✅ **DRY Principle**: Common request logic is consolidated into a reusable `sendRequest()` function
|
||||
- ✅ **Documentation**: Functions have clear JSDoc comments explaining purpose and parameters
|
||||
- ✅ **Organization**: Code is logically grouped with section headers and consistent formatting
|
||||
- ✅ **Error Handling**: Improved error handling using the new request function
|
||||
|
||||
### Adequate Implementation
|
||||
- ✅ **Constants**: Most repeated values are extracted, with minor hardcoded values remaining
|
||||
- ✅ **Factorization**: Basic `sendRequest()` function created but may not handle all edge cases
|
||||
- ✅ **Comments**: Key functions are documented, though some explanations could be more complete
|
||||
- ✅ **Readability**: Code is generally well-organized with some areas for improvement
|
||||
|
||||
### Needs Improvement
|
||||
- ❌ **Constants**: Many magic strings and URLs remain hardcoded throughout the file
|
||||
- ❌ **Duplication**: Significant code duplication remains between similar functions
|
||||
- ❌ **Documentation**: Missing or inadequate comments that don't explain the code's purpose
|
||||
- ❌ **Organization**: Code lacks clear structure and logical grouping
|
||||
|
||||
## Testing Your Refactored Code
|
||||
|
||||
After refactoring, ensure your banking app still functions correctly:
|
||||
|
||||
1. **Test all user flows**: Registration, login, dashboard display, and error handling
|
||||
2. **Verify API calls**: Confirm that your `sendRequest()` function works for both account creation and retrieval
|
||||
3. **Check error scenarios**: Test with invalid credentials and network errors
|
||||
4. **Review console output**: Ensure no new errors were introduced during refactoring
|
||||
|
||||
## Submission Guidelines
|
||||
|
||||
Submit your refactored `app.js` file with:
|
||||
- Clear section headers organizing different functionality
|
||||
- Consistent code formatting and indentation
|
||||
- Complete JSDoc documentation for all functions
|
||||
- A brief comment at the top explaining your refactoring approach
|
||||
|
||||
**Bonus Challenge**: Create a simple code documentation file (`CODE_STRUCTURE.md`) that explains your app's architecture and how the different functions work together.
|
||||
|
||||
- Extract constants, like the server API base URL
|
||||
- Factorize similar code: for example you can create a `sendRequest()` function to regroup the code used in both `createAccount()` and `getAccount()`
|
||||
- Reorganize the code to make it easier to read, and add comments
|
||||
## Real-World Connection
|
||||
|
||||
## Rubric
|
||||
This assignment mirrors the type of code maintenance that professional developers perform regularly. In industry settings:
|
||||
- **Code reviews** evaluate readability and maintainability like this assignment
|
||||
- **Technical debt** accumulates when code isn't regularly refactored and documented
|
||||
- **Team collaboration** depends on clear, well-documented code that new team members can understand
|
||||
- **Bug fixes** are much easier in well-organized codebases with proper abstractions
|
||||
|
||||
| Criteria | Exemplary | Adequate | Needs Improvement |
|
||||
| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
|
||||
| | Code is commented, well-organized in different sections and easy to read. Constants are extracted and a factorized `sendRequest()` function has been created. | Code is clean but can still be improved with more comments, constant extraction or factorization. | Code is messy, not commented, constants are not extracted and code is not factorized. |
|
||||
The skills you're practicing here - extracting constants, eliminating duplication, and writing clear documentation - are fundamental to professional software development.
|
||||
|
||||
@ -1,25 +1,148 @@
|
||||
# Implement "Add transaction" dialog
|
||||
# Implement "Add Transaction" Dialog
|
||||
|
||||
## Overview
|
||||
|
||||
Your banking app now has solid state management and data persistence, but it's missing a crucial feature that real banking apps need: the ability for users to add their own transactions. In this assignment, you'll implement a complete "Add Transaction" dialog that integrates seamlessly with your existing state management system.
|
||||
|
||||
This assignment brings together everything you've learned in the four banking lessons: HTML templating, form handling, API integration, and state management.
|
||||
|
||||
## Learning Objectives
|
||||
|
||||
By completing this assignment, you will:
|
||||
- **Create** a user-friendly dialog interface for data entry
|
||||
- **Implement** accessible form design with keyboard and screen reader support
|
||||
- **Integrate** new features with your existing state management system
|
||||
- **Practice** API communication and error handling
|
||||
- **Apply** modern web development patterns to a real-world feature
|
||||
|
||||
## Instructions
|
||||
|
||||
Our bank app is still missing one important feature: the possibility to enter new transactions.
|
||||
Using everything that you've learnt in the four previous lessons, implement an "Add transaction" dialog:
|
||||
### Step 1: Add Transaction Button
|
||||
|
||||
**Create** an "Add Transaction" button on your dashboard page that users can easily find and access.
|
||||
|
||||
**Requirements:**
|
||||
- **Place** the button in a logical location on the dashboard
|
||||
- **Use** clear, action-oriented button text
|
||||
- **Style** the button to match your existing UI design
|
||||
- **Ensure** the button is keyboard accessible
|
||||
|
||||
### Step 2: Dialog Implementation
|
||||
|
||||
Choose one of these two approaches for implementing your dialog:
|
||||
|
||||
**Option A: Separate Page**
|
||||
- **Create** a new HTML template for the transaction form
|
||||
- **Add** a new route to your routing system
|
||||
- **Implement** navigation to and from the form page
|
||||
|
||||
**Option B: Modal Dialog (Recommended)**
|
||||
- **Use** JavaScript to show/hide the dialog without leaving the dashboard
|
||||
- **Implement** using the [`hidden` property](https://developer.mozilla.org/docs/Web/HTML/Global_attributes/hidden) or CSS classes
|
||||
- **Create** a smooth user experience with proper focus management
|
||||
|
||||
### Step 3: Accessibility Implementation
|
||||
|
||||
**Ensure** your dialog meets [accessibility standards for modal dialogs](https://developer.paciellogroup.com/blog/2018/06/the-current-state-of-modal-dialog-accessibility/):
|
||||
|
||||
**Keyboard Navigation:**
|
||||
- **Support** Escape key to close the dialog
|
||||
- **Trap** focus within the dialog when open
|
||||
- **Return** focus to the trigger button when closed
|
||||
|
||||
**Screen Reader Support:**
|
||||
- **Add** appropriate ARIA labels and roles
|
||||
- **Announce** dialog opening/closing to screen readers
|
||||
- **Provide** clear form field labels and error messages
|
||||
|
||||
### Step 4: Form Creation
|
||||
|
||||
**Design** an HTML form that collects transaction data:
|
||||
|
||||
- Add an "Add transaction" button in the dashboard page
|
||||
- Either create a new page with an HTML template, or use JavaScript to show/hide the dialog HTML without leaving the dashboard page (you can use [`hidden`](https://developer.mozilla.org/docs/Web/HTML/Global_attributes/hidden) property for that, or CSS classes)
|
||||
- Make sure you handle [keyboard and screen reader accessibility](https://developer.paciellogroup.com/blog/2018/06/the-current-state-of-modal-dialog-accessibility/) for the dialog
|
||||
- Implement an HTML form to receive input data
|
||||
- Create JSON data from the form data and send it to the API
|
||||
- Update the dashboard page with the new data
|
||||
**Required Fields:**
|
||||
- **Date**: When the transaction occurred
|
||||
- **Description**: What the transaction was for
|
||||
- **Amount**: Transaction value (positive for income, negative for expenses)
|
||||
|
||||
Look at the [server API specifications](../api/README.md) to see which API you need to call and what is the expected JSON format.
|
||||
**Form Features:**
|
||||
- **Validate** user input before submission
|
||||
- **Provide** clear error messages for invalid data
|
||||
- **Include** helpful placeholder text and labels
|
||||
- **Style** consistently with your existing design
|
||||
|
||||
Here's an example result after completing the assignment:
|
||||
### Step 5: API Integration
|
||||
|
||||
**Connect** your form to the backend API:
|
||||
|
||||
**Implementation Steps:**
|
||||
- **Review** the [server API specifications](../api/README.md) for the correct endpoint and data format
|
||||
- **Create** JSON data from your form inputs
|
||||
- **Send** the data to the API using appropriate error handling
|
||||
- **Display** success/failure messages to the user
|
||||
- **Handle** network errors gracefully
|
||||
|
||||
### Step 6: State Management Integration
|
||||
|
||||
**Update** your dashboard with the new transaction:
|
||||
|
||||
**Integration Requirements:**
|
||||
- **Refresh** the account data after successful transaction addition
|
||||
- **Update** the dashboard display without requiring a page reload
|
||||
- **Ensure** the new transaction appears immediately
|
||||
- **Maintain** proper state consistency throughout the process
|
||||
|
||||
## Technical Specifications
|
||||
|
||||
**API Endpoint Details:**
|
||||
Refer to the [server API documentation](../api/README.md) for:
|
||||
- Required JSON format for transaction data
|
||||
- HTTP method and endpoint URL
|
||||
- Expected response format
|
||||
- Error response handling
|
||||
|
||||
**Expected Result:**
|
||||
After completing this assignment, your banking app should have a fully functional "Add Transaction" feature that looks and behaves professionally:
|
||||
|
||||
|
||||
|
||||
## Rubric
|
||||
## Testing Your Implementation
|
||||
|
||||
**Functional Testing:**
|
||||
1. **Verify** the "Add Transaction" button is clearly visible and accessible
|
||||
2. **Test** that the dialog opens and closes properly
|
||||
3. **Confirm** form validation works for all required fields
|
||||
4. **Check** that successful transactions appear immediately on the dashboard
|
||||
5. **Ensure** error handling works for invalid data and network issues
|
||||
|
||||
**Accessibility Testing:**
|
||||
1. **Navigate** through the entire flow using only the keyboard
|
||||
2. **Test** with a screen reader to ensure proper announcements
|
||||
3. **Verify** focus management works correctly
|
||||
4. **Check** that all form elements have appropriate labels
|
||||
|
||||
## Evaluation Rubric
|
||||
|
||||
| Criteria | Exemplary | Adequate | Needs Improvement |
|
||||
| -------- | --------- | -------- | ----------------- |
|
||||
| **Functionality** | Add transaction feature works flawlessly with excellent user experience and follows all best practices from the lessons | Add transaction feature works correctly but may not follow some best practices or has minor usability issues | Add transaction feature is partially working or has significant usability problems |
|
||||
| **Code Quality** | Code is well-organized, follows established patterns, includes proper error handling, and integrates seamlessly with existing state management | Code works but may have some organization issues or inconsistent patterns with the existing codebase | Code has significant structural issues or doesn't integrate well with existing patterns |
|
||||
| **Accessibility** | Full keyboard navigation support, screen reader compatibility, and follows WCAG guidelines with excellent focus management | Basic accessibility features implemented but may be missing some keyboard navigation or screen reader features | Limited or no accessibility considerations implemented |
|
||||
| **User Experience** | Intuitive, polished interface with clear feedback, smooth interactions, and professional appearance | Good user experience with minor areas for improvement in feedback or visual design | Poor user experience with confusing interface or lack of user feedback |
|
||||
|
||||
## Additional Challenges (Optional)
|
||||
|
||||
Once you've completed the basic requirements, consider these enhancements:
|
||||
|
||||
**Enhanced Features:**
|
||||
- **Add** transaction categories (food, transportation, entertainment, etc.)
|
||||
- **Implement** input validation with real-time feedback
|
||||
- **Create** keyboard shortcuts for power users
|
||||
- **Add** transaction editing and deletion capabilities
|
||||
|
||||
**Advanced Integration:**
|
||||
- **Implement** undo functionality for recently added transactions
|
||||
- **Add** bulk transaction import from CSV files
|
||||
- **Create** transaction search and filtering capabilities
|
||||
- **Implement** data export functionality
|
||||
|
||||
| Criteria | Exemplary | Adequate | Needs Improvement |
|
||||
| -------- | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | --------------------------------------------|
|
||||
| | Adding a transaction is implemented completely following all best practices seen in the lessons. | Adding a transaction is implement, but not following the best practices seen in the lessons, or working only partially. | Adding a transaction is not working at all. |
|
||||
These optional features will help you practice more advanced web development concepts and create a more complete banking application!
|
||||
|
||||
Loading…
Reference in new issue