Brand new designs for Acuity Scheduling are beautiful out of the box and make it easy to provide online appointment scheduling for you or your clients, matching their identity. The online scheduler comes with several templates, embeds quickly in existing websites, and is fully customizable with advanced CSS.
Over on the MediaTemple Blog, I talk about some logical possibilities for how you might arrange the declarations within a ruleset. Personally:
I'll admit, I traditionally haven't had much of an opinion about the ordering of CSS properties. I just add what I need. I think they end up largely "grouped" by related things because that's just how my brain spits them out.
While writing this, I looked into CSS Comb again, and I'm starting to be convinced this is a good idea. I don't know if it's worth the tedious work of manually organizing properties, but I can see the advantages of code that is meticulously organized, so having a computer do it seems like a good idea.
When does a project need React? That's the question Chris Coyier addressed in a recent blog post. I'm a big fan of Chris' writing, so I was curious to see what he had to say.
So today, I'm here to argue that the answer to "When does a project need React?" is not "it depends". It's "every time".
The "normal" workflow I'm sure we've all lived is that design happens, then coding happens. A healthy workflow has back-and-forth between everyone involved in a project, including designers and developers, but still: The code is the final product. You design your way to code, you don't code your way to designs.
It was only a little over a month ago when it was news that Sketch 43 was moving to a .JSON file format. The final release notes drop the news quite blasé:
Revised file format
But Jasim A Basheer rightly made a big deal of it:
... it will fundamentally change how the design tools game will be played out in the coming years.
"enables more powerful integrations for third-party developers" is stating it lightly. This is what the fine folks at Bohemian Coding has done — they opened up Sketch's file format into a neat JSON making it possible for anyone to create and modify Sketch compatible files.
CSS Custom Properties give us the ability to reach into a property value and change certain parts of it. That's useful in a bunch of places, but in particular, it's useful in properties which don't allow us to do it any other way.
It lists a whole bunch of PWAs out there and you can filter them by Lighthouse metrics – that’s the auditing tool from Google that scores a web app and gives us developers the ability to improve them.
To no one's surprise, I'm sure, there are lots of different ways to do the same thing on the web. Shape morphing, being a thing on the web, is no different. There are some native technologies, some libraries that leverage those, and some libraries that do things all on their own. Let's look at some of the options (with demos) and weigh the advantages and disadvantages.
If I had to blindly guess about global marketshare, I would have gotten it wrong. I probably would have forgotten about UC browser (kind of the point of Peter O'Shaughnessy's article) that's so huge in Asia. I would have guessed Firefox has a slight edge on Safari (turns out Firefox is half the share of Safari), and that Edge would be outpacing IE by now (also only half).
This is good dinner party conversation fodder, but I wouldn't base any major decision making on it. The only stats that matter at your websites stats.
I like to think of myself as having a decent amount of persistence. But of course, life is complicated. Sometimes I have it and sometimes I don't. I have in some areas and not in others. C'est la vie. Here's two very short things that I've written up along this theme.
There are few things more obnoxiously tedious than being asked to sign a document over email, where they tell you to print it, sign it, scan it, and email it back. One time I Photoshopped my signature onto a document, and they were able to tell somehow and made me go through the whole rigamarole instead.
We're working with highly sophisticated computers here, can't I sign this thing with the web somehow? Yes, you can! As long as the company asking is using eversign, that is.
The beautiful thing about Vue is that it's incredibly feature-rich. But even if you have an edge case not covered by the framework, it's got your back there as well, because you can quite easily create a custom directive.
As the need for these libraries fades, and we see a massive rise in new frameworks, I'd argue it's not as clear when to reach for them. At what point do we need React?
A couple of good posts on technology agnosticism lately.
Brad Frost says the design system itself is higher level than any particular technology:
... it doesn't bet the farm on any one technology, the system is able to adapt to inevitable changes to tools, technologies, and trends.
Jonathan Snook thinks Mustache is good choice for otherwise technologically agnostic templating:
I like it because of its simplicity and because it requires the heavy work with the data to be done before it sees a template.
Matt Rothenberg with a Vue.js tutorial playing off Shu Uesugi's 2015 article React.js Introduction For People Who Know Just Enough jQuery To Get By. Matt doesn't spend quite as much time comparing what building the UI component would be like in jQuery as compared to Vue as Shu did comparing with React, but it's just as well. It's literally the exact same UI component (a New Tweet box) as the React article, and now, 2 years later, without downplaying or knocking jQuery, most folks are ready to just jump in with new frameworks.
Remember we have a guide as well!