jorts/README.md

Introduction

In this Assignment, you will make a front-end-only single page app, using the skills of Unit 2. In particular, you will create an app for making a "mood board". I'm told that Pinterest can do this sort of thing.

You will write your solution using front-end technologies: HTML, CSS, and front-end JS. I have provided a few starter files for the frontend. You may use these as you wish, including modifying them, or starting over. All of this code should go in the static directory.

I have also provided a skeleton server, because some features do not work unless the frontend was delivered via file:. There is no reason to change this, please do not change this without consulting me, it would just be weird.

This Assignment is worth 25% of your final grade.

Due Date

This Assignment is due on Sunday, March 24th, at 11:59pm.

Submission

GitHub Classroom, same as before. If you changed GitHub username, be sure to tell me, same as before.

A Comment on CSS

I spent as much time on CSS as the rest of the assignment put together, nearly. Don't be as silly as me (don't waste so much time), but be warned that you will probably need to give yourself some time to do the CSS.

Intellectual Honesty

All the same notes apply as on previous assignments. This assignment is individual work. You may use tools that are not made of people, like textbooks, stack overflow, AIs unless they are secretly fake AIs where a human being is actually answering the chat, whatever. You may not ask others for help (except me), you may not look at the code of other students, you may not help other students, you may not show other students your code.

SOURCES.md is still a good idea, though still not strictly required.

Concepts

This is a piece of software for making a "mood board". A mood board is an arrangement of images (and usually other elements, but we'll stick to images), like a collage. So we need to let users add images, and arrange them, and resize them.

To bring a little bit of order to that plan, we'll actually be organizing our UI in terms of cards. Our cards will have two modes: display mode and edit mode. In display mode, a card will simply show the image, nothing more, nothing less. In edit mode, the card should still take up the same space, but the image should shrink so that there's room for buttons and other UI elements to modify the card (and thus modify how the image appears).

One other note: in a more complete version of this app, you'd need to be able to handle images with different aspect ratios (including cropping and scaling input images). In this app, we will just assume that all images have a 16:9 aspect ratio. You MAY choose to ignore this assumption, but then the responsibility is on you to do extra work to make it look good.

Functional Requirements

PASS

For this level, the web-app must be in a state to demo, to impress a client.

• Statement To Grader
  • As with previous work, please include a file called STATEMENT_TO_GRADER.md.
  • As with previous work, this file should start with "I believe I have completed 100% of the requirements for the ____ tier".
  • As with previous work, feel free to add anything else that you would like me to know as I grade your work.
• Main View
  • The main part of the page must be able to display zero or more cards.
    • "zero or more" means that if I add 200 cards, it should still work okay!
  • Each card is the host for an image, and in normal view the card displays only the image, with no other UI elements
  • Cards are displayed in a particular order, and initially they are displayed in the order they are added
  • Your layout does not need to be as fancy as mine, but please have some kind of layout that kinda makes sense.
• Cards
  • Cards always start in display mode, wherein they show only their image
  • Clicking on an image will toggle its card between display mode and edit mode
    • Also toggling one card to editing mode takes all other cards out of editing mode.
  • In edit mode, a card shows the image at a smaller size, plus some editing buttons
    • there's a delete button
      • if you're a better dev than me, you could add some kind of confirmation dialog
    • there are two buttons to move the card earlier or later in the order
    • there are two buttons to increase or decrease the size of the card
  • Cards can be moved earlier or later in the list, and they cannot be messed up by moving them too far (too early or too late)
  • Cards must have some type of "size" property, which can be varied (as mentioned above)
    • in my implementation, this size property is in multiples of 50px
      • if varying this slightly allows you to make a nice-looking app, that's fine, but don't stray too far
    • there should be lower and upper bounds on how small or large a card can get (in my case, 100px to 450px)
  • All button functionality must be implemented with delegates, so that there are not hundreds of active event listeners
    • My solution has 7 event listeners at the PASS level, but the exact number isn't important
    • But if I add ten more pictures to a mood board, and that adds 10 (or 50!) more listeners, that's not okay
• Header
  • There must be a header. The header must contain a name, and buttons for the following things: Add Image, Seed, Clear
  • The Add Image button must open a suitable modal dialog box, to allow adding images
    • This dialog, when active, must not be hidden behind other UI elements
    • The dialog should have a text input to allow the user to type in a URL
    • The dialog should have two buttons, or optionally three or four:
      • The Cancel button should close the dialog (i.e. make the dialog disappear)
      • The Add button should
        • add a new card, with its src set to the user-input URL
          • the new card is added after all the existing cards
        • close the dialog
        • error checking:
          • if the URL is empty, the Confirm button should do nothing at all
          • if the URL doesn't start with http:// nor https://, you should silently help the user out by guessing that they meant to add http://
          • otherwise, don't worry about error checking
      • Optional: the Add More button should
        • behave just like the Confirm button, but it doesn't close the dialog
          • (this is useful for testing, heh)
      • Optional: the Random button should add a random image
        • should it close the dialog or not, I don't know, you decide
    • When an image is added, create a new card and add it to the end of the list of cards
  • The Clear button should remove all cards (and thus all images) from the main view.
  • The Seed button should insert a few cards, at semi-random. They should have different images and different sizes. Pressing Seed a second time should bring in more images. There should be enough variety that it's easy to test if various features work.
• CSS
  • Your CSS should not be horribly ugly. This isn't really a class on CSS, but I know you all passed a class on CSS, and I know that you will be required to do CSS in the future, so I guess you gotta do some CSS.
    • In particular, when flipping back and forth from Edit mode to Display mode, a card should not be all jumping around like a junkie.
• Code Quality
  • As usual, I expect your code to be near to a professional level. If you've forgotten my thoughts on that, consider going back and re-reading the READMEs from previous assignments.
• XSS Prevention
  • I believe that there is only one opportunity for a bad guy to insert an attack into this app, and that is via the "Add Image" form. Make sure that the URL provided in this form is not unsafely interpolated into your HTML, please.

So, in short, you must be able to

• add images
• resize images
• move images
• delete images

That will require you to

• select DOM nodes
• create DOM nodes
• modify DOM nodes
• delete DOM nodes

SATISFACTORY

• Popped-Out Cards
  • Card gain a new edit button (visible only in edit mode), to "pop them out".
    • The button toggles between "Popped-Out" state and normal state
  • Popped-Out cards are pulled out of the normal flow of the other cards, as if they were absolute-positioned
    • The z-index of popped-out cards should be in front of normal-flow cards, but behind the Add Image dialog
    • You could pop cards out to the center of the screen, or perhaps to where they were before being popped out, or anything else that's reasonable and predictable
  • Popped-Out cards still use the same size rules as normal cards, and can still be resized somehow
  • Popped-Out cards no longer have a place in the order, and there should be no weird janky bugs related to this
  • Popped-Out cards should have a button (in edit mode) to return them to normal flow
    • For many reasons it is probably very difficult to put them in an intuitively-correct place...
    • So you should just put them at the end of the list of cards, as if they had just been Added
  • Popped-Out cards can also be moved
    • I think they should probably have buttons for Left and Right and Up and Down
    • But you could do something else, as long as it's at least as hard as 4 buttons
• localStorage
  • localStorage is an API that the browser provides to front-end JavaScript
    • read about it on MDN
      • https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
    • you can also read the following for completeness, but there's a lot of extra stuff there that I think you don't need
      • https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API/Using_the_Web_Storage_API
  • integrate your state-storage strategy with localStorage
  • every single change made to the page should be recorded in localStorage, so that if I refresh the page, everything returns as it was
    • that includes what images are where, in what order, what size, whether or not they're popped-out...
      • and in the case of popped-out cards, their position on the page
• Code Quality
  • You know the drill; write code you'd be happy with your boss seeing during code-review
  • I gotta be honest, I have no idea how to organize the code for a project like this.
    • Maybe you can figure something out. Take a shot, please.

EXEMPLARY

• Keybinds
  • It should be possible to do all editing tasks with the keyboard
    • You can leave out the adding-images if you want, and other functionality from the buttons in the Header
  • This means there must be some notion of a "currently selected" card, although it can be null/undefined (and it must be if there are no cards)
  • You must be able to press Tab and have the "current selection" move to the next card, and ideally Shift-Tab should go in the opposite direction
    • If there's nothing selected and the user pressed Tab, that means go to #1
    • It should be possible to loop around from the end to the beginning and vice versa
  • You must have a keybinding for every one of the edit buttons, so that I can resize and move and popout/popin from the keyboard.
    • Maybe no keybind for Delete, that just seems reckless, but it's up to you
  • When the app first loads, it should console.log a help message explaining all of the keybinds.
  • I used WASD for movement, + and - for size, P for Popout, but you can choose something else
• OPTIONAL: add a "Help" button to the Header, that explains all the keybinds
• Drag and Drop
  • Popped-out cards should be able to be moved with the mouse
    • Figure out where clicking-to-drag should work
  • This should be completely inter-operable with the existing means of moving things around
• Undo/Redo
  • Add undo/redo functionality, by adding buttons in the header
  • You do not need to save the undo/redo stack with localStorage
  • Also you need keybinds for undo/redo
    • I used Z and X, but you can choose something else