Added By: Feedage Forager Feedage Grade C rated
Language: English
container queries  container  desktop  device  devices  files  grid  homekit  hub  lightroom mobile  lightroom  mobile  specific  work 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics

Tips, Tricks and Bookmarks on Web Development.


Smart Home

Wed, 30 Aug 2017 20:33:18 +0000

A couple months ago, I bought a new car. However, I realized after the purchase that the car didn’t have a built-in garage door opener like my old car had. The new car has Apple CarPlay. I tried to use Siri in the car to open the garage door but to no avail. To which, I thought, maybe I should by a HomeKit powered garage door opener! This idea opened the floodgates of research into the world of having a “smart home”. I started buying smart switches and smart lights and smart thermostats and, wow, is this stuff complicated. Constraints I’m a fan of being able to easily move between ecosystems. I have Windows and macOS. I have Android and iOS. There’s voice control on the desktop, on mobile, and as a standalone device. Can I build a system that works across all of these? The short answer is: no. Long answer: we can come pretty damn close and maybe that’s okay. The other requirement I had was that anybody in the house shouldn’t necessarily need something complex to work the lights. I shouldn’t have to get them to install an app to be able to interact with the house. Not a terribly difficult requirement, per se, but there are some considerations here. How does it work? In the most vaguest terms, you have a device (light bulb, light switch, outlet, or whatever) that can communicate and be controlled by another device (hub, phone, voice device, or whatever). The trick is to get all the devices talking together. Communication The first thing to consider is how everything will communicate with each other. Here are just a few of the more popular ways: Z-wave Zigbee TCP/IP Bluetooth HomeKit Insteon Pick the wrong one and you might find yourself limited. I bought some Hue lights at first. They worked with HomeKit but I could also hook them up to Google Home. And as it turns out, a bunch of other stuff, too. Then I bought a switch that was HomeKit-enabled. Sadly, it only worked with HomeKit and nothing else. I had to pull it out and put something else in its place. Z-wave is probably the most popular with multiple hubs and devices that work on it. I decided to go that route since it had the best support. Again, with some caveats. Z-wave hubs like Wink and SmartThings don't work with HomeKit. They work with Alexa and Google Home, though. To fix the HomeKit integration, there’s an open source project called Homebridge that acts like an accessory that will sync all your devices to Homekit. You can run it on a Raspberry Pi, too, which is fantastic. Hubs Once you've figured out what protocol things will communicate with, you may need a hub. I say "may" because if you pick HomeKit, for example, then there's no hub. For pretty much everything else, there is. If you go the Hue lights route, there's a Hue hub. If you go Z-wave or Zigbee or Insteon, there's a hub that'll work for each of those. Since I went Z-wave, the two most popular hubs are Wink and SmartThings. I've heard good things about SmartThings, including how good the API is (if you're interested in programming). I went with Wink out of convenience; my local HomeDepot had them in stock. The Wink hub has an API, too. Hubs don't have a user interface. You'll need your phone or tablet to connect to the hub to make any changes to your configuration, such as adding or removing devices. The Wink app is pretty good for adding new devices from many different manufacturers with step-by-step instructions. Wink and SmartThings also support devices that use Zigbee or TCP/IP. With either of those hubs, you're pretty much golden. Devices Once you have a hub, now you need devices! Having decided on a hub, picking devices might seem like the easy part. Does it communicate with the hub? Yes? Great! But not so fast. Devices are a big part of the user experience. When somebody wants to turn on a light, how do they do it? How does it feel? Hue Hue lights, for example, sound fantastic. Great integration with pretty much everything. Ability to change colour to fit mood, sound, or time of day. With one huge flaw: the light switch.[...]

Photo Editing Workflow With Lightroom and Lightroom Mobile

Mon, 05 Jun 2017 12:43:43 +0000

From time to time, I like to take photos. (See Instagram and Flickr.) I have a couple phones and a couple DSLRs. Over the years, I’ve muddled my way through different processes and have struggled to find something that felt easy and effortless—especially when working across multiple devices like I do. In the past, I’d move all images off a device, into a big ol’ folder, sorted by date, and then eventually moved off to external drives for safe keeping. That really didn’t take into account the editing of said images. Enter Lightroom. I had been playing with Lightroom on the desktop for a little while but never quite made a routine of it. With a purchase of a more recent DSLR that lets me transfer images directly to my phone or tablet, however, I found myself wanting to ditch the laptop and do editing directly on my mobile device. At first, I was transferring over JPGs, editing in VSCO or Instagram, and then posting right away. This had been good enough that I actually became quite lax in managing my photo collection. Along came iOS 10, with RAW image support, and suddenly I wanted something to take advantage of that. Lightroom once again came to mind. This time, Lightroom Mobile (LRM). Since it supports editing RAW files, I decided to try my hand at using just Lightroom Mobile with my phone or tablet to manage things. I could add my images to LRM and they could sync across all my devices—including desktop. This is where it all gets a bit confusing. First of all, the syncing of photos to desktop is slow as molasses. I had 1500 photos and it took a day to download to my desktop. The other problem was that it downloaded everything to the desktop. Nothing was stored in the cloud and downloaded when needed. This is when I realized that this mobile workflow wasn’t going to work. I couldn’t store my entire photo collection and have it sitting on my desktop. I’d run out of hard drive space. After some fiddling with trying to understand the relationship between folders, catalogs, and collections, I realized that Lightroom Mobile is a slightly less effort way of being able to work on a small set of files and move them between desktop and device. For me, the key is that when Lightroom Mobile syncs my photos to my desktop, I organize them with my usual folder naming convention. (Folder per year and folder per month, with specific folders for specific trips. e.g “/2016/2016-11 Atlanta”.) Once I’m done with a set of photos, I create a Lightroom catalog for that set and then move the catalog and photos over to the external drive. (And from there, I make additional backups of that drive.) Lightroom Mobile, then, is relegated to just moving the occasional file across device, to be removed once I’ve done what I want with it, such as upload to Instagram. (Lightroom on the desktop lets me sync to Facebook or Flickr, so Mobile isn’t needed there.) Other Workflows One of the workflows I had hoped to have with the iPad was quickly move between Adobe apps such as Mix, Fix, or Express, tweaking the images to get them to where I want. Sadly, if it supported files in Lightroom, files needed to be synced to the cloud and back again. It made editing files slow and cumbersome. If it didn’t support Lightroom, then files were converted to flat JPGs, returned to Lightroom as a completely new image. I didn’t really want multiple copies of essentially the same file. If I chose to keep the files in the iOS format, I could use Google SnapSeed to do edits and have it save to the original file, allowing me to revert changes if I desired. Sticking to Lightroom With my desire to move between iOS, Android, macOS, and Windows, I really felt like Lightroom came the closest to solving my problem. Some things aren’t very intuitive. Some of it felt like institutional knowledge about how Lightroom works. Now that I understand it better, it’s easier for me to move a bunch of files and the catalog file between desktop environments. I believe Adobe has an opportunity here to solve[...]

Container Grids

Mon, 24 Apr 2017 20:38:39 +0000

There’s been a rumbling of people that want Container Queries—myself included. (Come see my talk this year... it’s all about container queries!)

The idea behind container (née element) queries is that you specify that under certain conditions—most commonly, the width of a particular container—apply different CSS.

The problem with container queries is that it opens up the window for circular references. You could theoretically have CSS that says the following: if the width of the container is under 500px then make the contents 600px. At which point, your container is no longer under 500px and the CSS is no longer applied. At which point, the contents are no longer 600px and the width of the container is now back under 500px and the CSS should be applied. That’s bad.

In my exploration of CSS grids, I’ve been building a mental model of how they work. Let’s start with the following example:

.grid {
    display: grid;
    grid-template-columns: 200px 500px;

Guess what happens when the container doesn’t have enough room for the two columns? It just overflows the container. There’s no reflow and the container remains the same size.

Container Grids?

One purpose for container queries is to specify different layouts. Maybe adjust the size of something or rearrange something.

My “what if” lightbulb wondered if there were a way that we could one day solve the container query circular reference problem by using a grid layout system exclusively with container queries. (Other layout systems could still be used. They just couldn’t be used in conjunction with container queries.)

Since this system would be specific to grid, I’m imagining a syntax similar to responsive images that allows you to specify the minimum width for which the grid would apply.

.grid {
    display: grid;
        200px 300px 600w, 
        200px 200px 1fr 900w;

Container Other?

This doesn’t solve the problem of how to apply other design changes like font and colour changes or margin and padding changes that would also be applicable under those conditions.

I don’t have an eloquent solution for that. It’d need to be something that can deal with the cascade.

Now, I’m just spitballing here and don’t know enough about how the CSS specification works to know whether this could even work but what if you could name those grid templates?

.grid {
    display: grid;
        200px 300px 600w tablet, 
        200px 200px 1fr 900w desktop;

From there, being able to style elements using those keywords.

.item:grid(tablet) {
    padding: 20px;

.item:grid(desktop) {
    padding: 40px;

Due to inheritance, the keywords would be applicable to child elements. If you have a grid inside a grid then the same inheritance rules apply, with the child element outranking the parent element.

You could have the same cascade rules, too.

Where to go from here?

I suspect there are many holes in this idea. But maybe it’s enough to spur someone somewhere along the way to make container queries a reality.

Template Technology Agnosticism

Tue, 18 Apr 2017 15:02:07 +0000

Brad Frost recently wrote about managing technology-agnostic design systems. In his post, he recommends using a technology that doesn’t tie itself to any specific framework. When I was at Yahoo!, we took a very similar approach. We knew we wanted to build out these components and be able to use them across multiple projects. And due to product acquisitions or teams deciding different stacks, we knew that we had the real possibility of needing to support templating in JavaScript, PHP, and Java environments. Mustache We chose Mustache because of its agnostic approach. (Pattern Lab—of which Frost is a contributing member—also uses Mustache under the hood.) It’s an approach that worked well for us at Yahoo! and one that I’ve been advocating for ever since. Like Frost says in his post, we wired up much of the system using some lightweight JavaScript for simple interactions. Some components, however, had a full JavaScript API. Something like an autocomplete widget would have Mustache, CSS, and JavaScript counterparts that would all be part of the final deliverable to other teams. Our prototyping engine was able to render (at request time) a small part or a large part of a page through a combination of file hierarchy and naming convention. And all of this was done outside of any team’s engineering efforts. The advantage to separating this out from other teams allowed us to avoid the complexity of their build process and release cycles—of which, different teams had different processes and different cycles. Single Stack On the flip side, when I was at Xero, I had made a different recommendation. Instead of an agnostic design system, I recommended picking a specific tech stack. Xero, too, had different tech stacks used across the application. Unfortunately, the plethora of platforms was more a hindrance, slowing down the ability to iterate on design and maintaining a consistent experience across the entire application. Some parts of the application wouldn’t have a team looking after it and thus would languish. Likewise, it was difficult to have people who had knowledge of all the tech stacks to roll design changes out system wide. As a result, inconsistency grew over time. By choosing a single tech stack, the intent was to build an API that allowed new projects to ramp up quickly while also allowing designers and front-end developers to roll out changes across the entire platform. Decisions When do you choose an agnostic platform versus a specific one? I believe it comes down to an organizational one. At Yahoo!, the Mustache templates were the source of truth. Thus, any design changes started within the prototyping platform and then pushed out to other teams. For that approach to work at Xero, a generic platform would need to be established as a source of truth and then pushed to an intermediate stage. Personally, I’m not sure that the intermediate stage is necessary. The more layers between designers and production, the more resistance to change is likely to occur. As Brad Frost intimates, if you’re using an intermediate step, you’re going to need a build process that converts the generic components into platform-specific ones. You’ll want to do this to avoid platform-specific implementations from becoming the new source of truth for any implementation. Otherwise, changes will have to roll back and forth between intermediary and preliminary stages. Conclusion I’m a big fan of Mustache, even over its more feature-laden cousin, Handlebars. 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. (This is a strategy I’ve been using in web development for 15 years now and I find it works well.)[...]