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".
I’m usually building one of three things: a demo, a prototype, or a minimum viable product (MVP).
I’ve seen some confusion over these terms — some people seem to use them somewhat interchangeable. But they’re not the same thing, and building one when you need another can cause problems.
This is a very useful distinction!
A look at the trend towards larger and larger font sizes for body copy on the web, culminating with Resilient Web Design.
There are some good arguments here for the upper limit on the font size there being too high, so I’ve adjusted it slightly. Now on large screens, the body copy on Resilient Web Design is 32px (2 times 1em), down from 40px (2.5 times 1em).