The Twitter character limit is a major factor of what can make it so much fun to use: you can read, publish, and interact, in extremely short, digestible chunks. But, it doesn’t fit every topic, ever time. Sometimes you want to talk about complex topics, having honest, thoughtful discussions. In an environment that encourages hot takes, however, it’s often easier to just avoid having those discussions. I can’t blame people for doing that, either: I find myself taking extended breaks from Twitter, as it can easily become overwhelming.
For me, the exception is Twitter threads.
Twitter threads encourage nuance and creativity.
Creative masterpieces like this Choose Your Own Adventure are not just possible, they rely on Twitter threads being the way they are.
And Tumblr screenshot threads are always fun to read, even when they take a turn for the epic (over 4000 tweets in this thread, and it isn’t slowing down!)
Tumblr textposts thread, probably?
— we are a family forged in bureaucracy (@ex_aItiora) August 26, 2019
Everyone can think of threads that they’ve loved reading.
My point is, threads are wildly underused on Twitter. I think I big part of that is the UI for writing threads: while it’s suited to writing a thread as a series of related tweet-sized chunks, it doesn’t lend itself to writing, revising, and editing anything more complex.
To help make this easier, I’ve been working on a tool that will help you publish an entire post to Twitter from your WordPress site, as a thread. It takes care of transforming your post into Twitter-friendly content, you can just… write.
It doesn’t just handle the tweet embeds from earlier in the thread: it handles handle uploading and attaching any images and videos you’ve included in your post.
All sorts of embeds work, too.
It’ll be coming in Jetpack 9.0 (due out October 6), but you can try it now in the latest Jetpack Beta! Check it out and tell me what you think.
This might not fix all of Twitter’s problems, but I hope it’ll help you enjoy reading and writing on Twitter a little more.
I can’t think of a more unequivocal title than that.
The Australian government doesn’t have a good track record of either launching publicly visible software projects, or respecting privacy, so I’ve naturally been sceptical of the contact tracing app since it was announced. The good news is, while it has some relatively minor problems, it appears to be a solid first version.
Privacy
While the source code is yet to be released, the Android version has already been decompiled, and public analysis is showing that it only collects necessary information, and only uploads contact information to the government servers when you press the button to upload (you should only press that button if you actually get COVID-19, and are asked to upload it by your doctor).
The legislation around the app is also clear that the data you upload can only be accessed by state health officials. Commonwealth departments have no access, neither do non-health departments (eg, law enforcement, intelligence).
Technical
It does what it’s supposed to do, and hasn’t been found to open you up to risks by installing it. There are a lot of people digging into it, so I would expect any significant issues to be found, reported, and fixed quite quickly.
Some parts of it are a bit rushed, and the way it scans for contacts could be more battery efficient (that should hopefully be fixed in the coming weeks when Google and Apple release updates that these contact tracing apps can use).
If it produces useful data, however, I’m willing to put up with some quirks.
Usefulness
About how the Australian COVIDSafe app helps with contact tracing. A thread. This is from the perspective of an epidemiologist – I don't have any expertise on the technical or privacy aspects.https://t.co/JB4hhrB4x6
I’m obviously not an epidemiologist, but those I’ve seen talk about it say that yes, the data this app produces will be useful for augmenting the existing contact tracing efforts. There were some concerns that it could produce a lot of junk data that wastes time, but I trust the expert contact tracing teams to filter and prioritise the data they get from it.
Install it!
The COVIDSafe site has links to the app in Apple’s App Store, as well as Google’s Play Store. Setting it up takes a few minutes, and then you’re done!
It absolutely was, and congratulations to everyone involved! Inspired by the fine work done to get another release out, I finally completed the last step of co-leading WordPress 5.0, 5.1, and 5.2 (Bebo, Betty, and Jaco, respectively).
At WordCamp Europe this year, I had the opportunity to chat with the folks at WP&UP, who are doing wonderful work providing mental health support in the WordPress community.
As React (via Gutenberg) becomes more present in the WordPress world, I’m seeing some common themes pop up in conversations about it. I spoke a bit about this kind of thing at WordCamp US last year, but if you don’t feel like sitting through a half hour video, let me summarise my thoughts.
I agree that React is hard. I strongly disagree with the commonly contrasted view that HTML, CSS, PHP, or vanilla JavaScript are easy. They’re all just as hard to work with as React, sometimes more-so, particularly when having to deal with the exciting world of cross-browser compatibility.
The advantage that PHP has over modern JavaScript development isn’t that it’s easy, or that the tooling is better, or more reliable, or anything like that. The advantage is that it’s familiar. If you’re new to web development, React is just as easy anything else to start with.
Something I’m seeing a lot.
Beginners: This makes sense, we understand it.
Experienced developers: There’s no way beginners would understand it. It’s not like <a thing I learned ten years ago>.
I’m honestly shocked when someone manages to wade through the mess of tooling (even pre-Gutenberg) to contribute to WordPress. It’s such an incomprehensible, thankless, unreliable process, the tenacity of anyone who makes it out the other side should be applauded. That said, this high barrier is unacceptable.
I’ve been working in this industry for long enough to have forgotten the number of iterations of my personal development environment I’ve gone through, to get to where I can set up something for myself which isn’t awful. React wasn’t around for all of that time, so that can’t be the reason web development has been hard for as long as I remember. What is, then?
Doing Better
Over the past year or so, I’ve been tinkering with a tool to help deal with the difficulties of contributing to WordPress. That tool is called TestPress, it’s getting pretty close to being usable, at least on MacOS. Windows support is a little less reliable, but getting better. If you enjoy tinkering with tools, too, you’re welcome to try out the development version, but it does still has some bugs in it. Feedback and PRs are always welcome! There are some screenshots in this issue that give an idea of what the experience is like, if you’d like to check it out that way.
TestPress is not a panacea: at best, it’s an attempt at levelling the playing field a little bit. You shouldn’t need years of experience to build a reliable development environment, that should be the bare minimum we provide.
React is part of the solution
There’s still a lot of work to do to make web development something that anyone can easily get into. I think React is part of the solution to this, however.
React isn’t without its problems, of course. Modern JavaScript can encourage iteration for the sake of iteration. Certainly, there’s a drive to React-ify All The Things (a trap I’m guilty of falling into, as well). React’s development model is fundamentally different to that of vanilla JavaScript or jQuery, which is why it can seem incomprehensible if you’re already well versed in the old way of doing things: it requires a shift in your mental model of how JavaScript works. This is a hard problem to solve, but it’s not insurmountable.
Perhaps a little controversially, I don’t think that React is guilty of causing the web to become less accessible. At worst, it’s continuing the long standing practice of web standards making accessibility an optional extra. Building anything beyond a basic, non-interactive web page with just HTML and CSS will inevitably cause accessibility issues, unless you happen to be familiar with the mystical combinations of accessible tags, or applying aria attributes, or styling your content in just the right way (and none of the wrong ways).
React (or any component-based development system, really) can improve accessibility for everyone, and we’re seeing this with Gutenberg already. By providing a set of base components for plugin and theme authors to use, we can ensure the correct HTML is produced for screen readers to work with. Much like desktop and mobile app developers don’t need to do anything to make their apps accessible (because it’s baked into the APIs they use to build their apps), web developers should have the same experience, regardless of the complexity of the app they’re building.
Arguing that accessibility needs to be part of the design process is the wrong argument. Accessibility shouldn’t be a consideration, it should be unavoidable.
Do Better
Now, can we do better? Absolutely. There’s always room for improvement. People shouldn’t need to learn React if they don’t want to. They shouldn’t have to deal with the complexities of the WCAG. They should have the freedom to tinker, and the reassurance that they can tinker without breaking everything.
The pre-React web didn’t arrive in its final form, all clean, shiny, and perfect. It took decades of evolution to get there. The post-React web needs some time to evolve, too, but it has the benefit of hindsight: we can compress the decades of evolving into a much shorter time period, provide a fresh start for those who want it, while also providing backwards compatibility with the existing ways of doing things.
