Area of a room with Alina
Hi, there. You're not logged in. So, you must be a visitor. Welcome!
What is this? You are viewing one of our supplemental "Stories." In addition to our core design curriculum, we are constantly building out additional resources. Stories are a collection of real work tasks, design history, UX explorations, and work-throughs. Stories are often off-the-cuff and less concerned with production value.
Introduction
Alina and Derek were hanging out and revisiting a bunch of JS interface concepts. So, we were putting those here for practical reasons.
But, this brings up an interesting point. In a world with a million boot camp grads with the same portfolio showing the same 4 projects with ugly thumbnails and no story… this page of CodePens might actually be an even better way to prove your skills.
You don’t have to make a fully finished web application to show that you know JavaScript and that you know it at many levels and can reason about it and explain it.
1. Just the JS
See the Pen HTML cheatsheet 1 / display types by perpetual.education (@perpetual-education) on CodePen.
If you can’t do it without the form ui, you’ll know it’s too tightly coupled to the template.
Sometimes we’re in a rush, and we don’t write out the pseudocode, but that usually comes back to haunt us (and cost a lot more time). So – if you’re in a rush, then you know it’s even more important to make a clear plan. Planning out what you want to do, is part of the work, and what if someone else needs to take over? This way, all of your time is of value even if you have to switch gears and come back to it later.
Also, you might need to unit-test the functions, and you might also test the form actions. So, they need to be separate and then composed together.
Key
concept
Eagleson's Law
“Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.”
(No one seems to know for sure who said this) (but there are people posting it as early as 1987)
It doesn’t need to take years or months or weeks or even a day to get lost in your own code. It could have been 5 minutes ago! So, start with the damn pseudocode, OK? And put some comments explaining your thought process in there. (If the code ends up being perfectly self-documenting later, great. Right now, it probably isn’t)
2. With a form
See the Pen HTML cheatsheet 1 / display types by perpetual.education (@perpetual-education) on CodePen.
OK. This works. It’s the first stage. You could probably commit this code as a reasonable step.
But it would be nice to align it more directly to the pseudocode instead of one long procedure (that might get longer and longer). watch for clicks → calculate it
3. With a handler
See the Pen HTML cheatsheet 1 / display types by perpetual.education (@perpetual-education) on CodePen.
The code is a little cleaner now. But using the form is the same. The user doesn’t care about your code.
This UX could be better. When you click the button, you can hardly tell if something changed.
4. With better UX
See the Pen HTML cheatsheet 1 / display types by perpetual.education (@perpetual-education) on CodePen.
If you had no message to start with, that might be better. Or maybe having the output there helps teach the user how it works? It would depend on the use case.
But maybe removing the message anytime the data has changed would help reset the user’s focus on the inputs and then they’d be ready for a fresh message when the hit submit.
What are the edge cases?
Getting your form “done” for school… isn’t the goal. And most of the time, when people feel like they’re done, they’re really 20% done. Remember, someone with experience is going to be looking at this.
There are no user errors. If a user can’t use it successfully, then you designed it poorly.
-
What if the user puts in a zero or a negative number? What about letters?
-
What are the pros and cons of native HTML 5 form input validation and custom validation messages?
-
How does it look on a really small screen?
-
Have you had other developers look at your code and give you review/feedback?
-
Whether it’s supposed to look like a wireframe or a finished product, does it look legit?
-
Is anything asynchronous? Should there be any animations to help explain what is happening?
-
Is it 100% accessible, keyboard navigable, and checked on screen readers?
-
Is it delightful?
5. With input event (better UX?)
See the Pen HTML cheatsheet 1 / display types by perpetual.education (@perpetual-education) on CodePen.
What if there was no submit button, and it just automatically calculated with any user input? Would this be better? (as always, it depends)
6. Showing paint buckets
See the Pen HTML cheatsheet 1 / display types by perpetual.education (@perpetual-education) on CodePen.
Maybe showing a representation of the physical paint buckets is the best way to get the information across?
Showing paint bucket left overs
See the Pen HTML cheatsheet 1 / display types by perpetual.education (@perpetual-education) on CodePen.
But they look upside down!
What’s next?
You may not have a secret dream of working for Sherwin-Williams (after all, their logo is literally pouring paint on top of the whole planet) – but if you take this all the way to a super fleshed-out animated paint measuring application, you’re going to be as qualified as anyone.
Is this type of exploration interesting to you? Looking for some depth?
Check out what we’re doing at PE. We’re interested in the big-picture design process. Sure, it’s going to involve code. But that’s just one part of designing delightful experiences.