DEV Community: Camden Clark

Why can't browsers natively handle cookie consent?

Camden Clark — Mon, 29 Mar 2021 09:18:54 +0000

With the implementation of GDPR and CCPA, every website has to have their own half-baked implementation of a cookie consent banner. For the uninitiated, these are the banners that appear at the bottom of webpages that say "Accept Cookies" or "Decline". These banners can sometimes take up half the viewport or not be responsive on mobile. Moreover, it's really common that these banners often have serious accessibility issues that might make them non-compliant.

There should be a better way.

What if browsers could have a similar native UX implementation for cookie consent as with getting access to the microphone, for example? The user experience I'm thinking about here is as follows: the user would be prompted in the browser context whether or not to allow access to cookies when navigating to a webpage. There's a lot of room in the design space here to make sure that the user is in control while minimizing the damage to the user experience on the web.

Before I get in to a few roadblocks I see, there could be ongoing work in this space, but some googling didn't help me here. If it's not being worked on, there's probably a few other reasons this hasn't been done yet (this is just a random thought I had), so please leave a comment if I've missed something.

Roadblock 1: Old browser versions

This is inevitably a huge roadblock. But we already have a bad patchwork of implementations, so it seems like that damage has been done here. Why not try to move towards a better standard?

Roadblock 2: Not granular enough

It's probable that a cookie interface for the browser wouldn't be granular enough to support all use cases (say, missing different levels of cookies to opt-in to). But, again, I think websites that want to support use cases outside of regulatory frameworks should probably implement their own interfaces. Getting 95% of the way there seems worth it.

Roadblock 3: Regulatory patchwork

This is probably the main roadblock for the near future. A lot of these laws are in their infancy, and many jurisdictions are considering their regulatory frameworks on data privacy right now.

This could be totally naive, but this could actually be an argument for writing a standard now. If there's a consistent standard that gets negotiated with all parties at the table, it would be way easier to lobby governments across the world that they should write regulation that matches the standard.

I'll just reiterate: I'm not super familiar with this area or what ongoing work or discussions have been had in the past here. Just sketching out some thoughts I had and found it difficult to find any information about decisions in this space.

Thanks for reading!

Why don't voice apps see more adoption?

Camden Clark — Sat, 08 Aug 2020 06:23:51 +0000

I read this summary of smart speaker usage and was struck by how little adoption third party smart speaker apps are gaining. It's not particularly surprising: just ask anyone not super familiar with the technology if they've used an Alexa skill. It seems like the third party ecosystem would have been more robust by now.

A Quick Note on Discoverability

From what I've been reading, there's a ton of discourse in the voice application community on discoverability. Sure, discoverability is really important for lots of applications. Ask yourself this: how many of the applications on your phone did you install after finding them in the app store?

I don't think discoverability is the key. If users were getting consistent value, we'd see adoption.

It's all about jobs to be done

What can your user accomplish that they can't accomplish easier by picking up their phone?

I think the Jeopardy skill is an excellent example--it's actually easier to dictate answers to Jeopardy than it is to write them on your phone.

There are a ton of reasons why the subset of jobs to be done with third party voice apps is really small right now. What do you think is the key?

mirrored here

Github Actions: What you might want to know

Camden Clark — Thu, 06 Aug 2020 05:58:06 +0000

I really wanted to try out github actions for my newest project, plaud.io. So I did.

It's a CI/CD tool that's fully integrated into your github repo workflow.

The jist is this: you have workflows, which run completely independently. You have jobs inside those workflows, which can run independently or based on a a DAG style dependency model. And, inside jobs you have steps. Each step is either a shell command you specify, or there are pre-baked steps built by the community.

What I liked

It's absurdly easy to get started. I was able to go from nothing to building my projects in about 30 minutes, which is really excellent.

Secrets are available right at your fingertips, there's no misdirection, you just set up secrets in your environment and you can inject them anywhere.

Everything is in the same space. I don't have to integrate with another CI/CD tool, and for a simple project it is nice to have things all in the same space.

I used a few pre-baked steps: google cloud cli setup, publish to npm if there's a new version, and a cached npm install. All of the pre-baked steps I used worked without much fanfare. One of these was a pretty nascent open source project, so it's nice that they work well and are reliable!

It's also really easy to change the things that trigger a specific workflow. Built into each workflow you can specify which files changing would run a specific workflow, only trigger them on PR, only on certain tags, etc. This is really batteries included.

What was kind of cumbersome

Let's say I had this project structure:

lib/ - a private node library deployed to a private npm repo
frontend/ - depends on lib from npm
backend/ - depends on lib from npm

I wanted to be able to build and publish lib first, then build the frontend and backend. This is totally possible and quite easy.

There's a few caveats here:

[It's my understanding that] you have to specify the working directory on every single step. It would be really nice to be able to specify a working directory once per job. I guess you can specify an environment variable and then use that, but it's still a lot of boilerplate.
You can't conditionally run jobs based on changes in the repo. It would be awesome to avoid building and deploying the backend if there are no changes to backend/ or lib/. I guess I could build my own pre-baked step in a docker container and just short-circuit the job if there's no changes...but that's a lot of work I feel like I shouldn't have to do. This functionally means you're forced to run a long deploy script even if there are no changes, or you split them all into different workflows.
I was a little frustrated that some of the pre-baked steps didn't allow you to specify working-directories. I think it would be nice to be able to run a step in the context of a working-directory even if the step doesn't have an explicit setting for it. There's probably some technical reason for being unable to do this, but not super clear to me.

A couple other separate things

I have a background in clojure, and the tooling for that didn't seem very well developed. I'd definitely do some investigation if you're using a less popular technology if you don't want to do a ton of bootstrapping.

One other separate thing: I really couldn't get the workflow exclude paths feature to work. Kind of annoying, but I didn't end up doing it.

Conclusion

Overall, a really positive experience using github actions. I think as it matures it will be much easier to use, but for now, if you're taking on a heavy project with lots of weird build steps, you might want to pick up something more tried and true.