I’ve always maintained that prototyping and production require different mindsets. Trys suggests it’s not as simple as that.
I agree with much of what he says about back-end decisions (make it manual ‘till it hurts—avoid premature optimisation), but as soon as you’re delivering HTML, CSS, and JavaScript to real people, I think you need to meet certain standards when it comes to accessibility, performance, etc.
The best reason to write a library in plain JavaScript is that it lasts forever. This is arguably JavaScript’s single most underrated feature. While I’m sure there are some corner cases, JavaScript from 1999 that ran in Netscape Navigator will run unaltered, alongside modern code, in Google Chrome downloaded yesterday. That is true for very few programming environments.
And yet:
Of course, most people’s experience with JavaScript is that it ages like milk. Reopen a node repository after 3 months and you’ll find that your project is mired in a flurry of security warnings, backwards-incompatible library “upgrades,” and a frontend framework whose cultural peak was the exact moment you started the project and is now widely considered tech debt.
It looks like it will be a great tool for prototyping. A tool to help developers that don’t have experience with CSS and layout to have a starting point. As someone who spent some time building smoke and mirrors prototypes for UX research, I welcome tools like this.
What concerns me is the assertion that this is production-grade code when it simply is not.
A good looking artifact too early in the process gains buy-in too quickly and kills discovery.
Chat is rarely a suitable interface for most tasks. Here, Maggie Appleton explores and prototypes some alternatives.
So then the question becomes: how do you most effectively communicate designs, to facilitate the best discussions about those designs? My answer is: lots of little prototypes built with HTML, CSS, and JavaScript.
I really enjoyed this deep dive into some design fiction work done by Fabien Girardin, Simone Rebaudengo, and Fred Scharmen.
(Remember when Simone spoke at dConstruct about toasters? That was great!)
I’m 100% convinced that working demo-to-demo is the secret formula to making successful creative products.
A stylesheet to imitate paper—perfect for low-fidelity prototypes that you want to test.
This is such a handy tool for building forms! Choose different combinations of type, inputmode, and autocomplete attributes on input elements and see how that will be conveyed to users on iOS and Android devices.
The next best thing to having Kurt Vonnegut at the blackboard.
It sometimes feels like we end up testing the limitations of our tools rather than the content and design itself.
What Benjamin found—and I heartily agree—is that HTML prototypes give you the most bang for your buck:
At the point of preparing for usability testing, it seemed ludicrous to move to any prototyping material other than the one we were already building in. The bedrock of the web: HTML, CSS and Javascript.
If you employ a hack, don’t be so ashamed. Don’t be too proud, either. Above all, don’t be lazy—be certain and deliberate about why you’re using a hack.
I agree that hacks for prototyping are a-okay:
When it comes to prototypes, A/B tests, and confirming hypotheses about your product the best way to effectively deliver is actually by writing the fastest, shittiest code you can.
I’m not so sure about production code though.
If you’ve been following my recent blog posts about a declarative option for the Web Share API, you might be interested in this explainer document I’ve put together. It outlines the use case for button type="share".
Great typography on the web should be designed in layers. The web is an imperfect medium, consumed by countless different devices over untold numbers of network connections—each with their own capabilities, limitations, and peculiarities. To think that you can create one solution that will look and work the same everywhere is a fantasy. To make this more than just one nice book website, the whole project and process needs to embrace this reality.
I never thought of combining the datalist element with input type="color"—it’s pretty cool that it just works!
Here’s one simple, practical way to make apps perform better on mobile devices: always configure HTML input fields with the correct
type,inputmode, andautocompleteattributes. While these three attributes are often discussed in isolation, they make the most sense in the context of mobile user experience when you think of them as a team.
This is an excellent deep dive with great advice:
You may think that you are familiar with the basic
autocompleteoptions, such as those that help the user fill in credit card numbers or address form fields, but I’d urge you to review them to make sure that you are aware of all of the options. The spec lists over 50 values!
A history of typesetting from movable type to variable fonts.
A brief history of the manicule, illustrated with some extreme examples.
Some solid research here. Turns out that using input type=”text” inputmode=”numeric” pattern="[0-9]*" is probably a better bet than using input type="number".