You can now privately comment / reply to this blog via email, thanks to our very first bit of Remark.as functionality, launched today. If you’re an email subscriber, go ahead and give it a shot! Otherwise, now is a great time to subscribe to email updates:
Two new customization options I’d like to add next, which will add some clutter to the Customize page:
- Remove Write.as branding with one click
- Let people reply to your posts via email
The first is a convenience feature — people can already remove the branding with a CSS workaround, but they’d have to go digging for it. This brings it to the forefront, gives people an explicit reason to upgrade to Pro, and will be the first in array of new custom branding options, including the ability to update your blog’s favicon on your own (instead of having us update it for you).
Then, email replies will be the first Remark.as feature we release. If you have Email Subscriptions enabled, you’ll be able to supply a “Reply-To” address that readers will reach if they hit “Reply” to one of your emails. This is simple and low-tech, but will serve to enable direct interaction on the platform — a very first for us.
Over the past few days, I developed a variety of spam-fighting tools for Write.as. Where we only had account silencing and IP address banning in place before, now we can actively block user registrations using certain email addresses — whether individual addresses or entire domains. I’ve also combined all possible actions for known spammers — silence, ban email, ban IP — into a single “block” action.
Next, I plan to create a process for human users to go through to verify their status as a non-spammer. This will essentially be a custom captcha test particularly suited for Write.as, which doesn’t rely on any third parties (like Google). If that works well, we should be able to adequately stop spammers through automated filtering (which is working quite well), while allowing real users to slip through and use the platform with minimal interruption.
One question: where is the line between writing as “you” and distributing that writing as “Matt” or “Anonymous” or “John Doe” or whatever you choose to go by? I could imagine that the blog selector menu we have in the Write.as editor right now enables writers to “put on the clothes” of whatever alias they’re publishing under, perhaps getting them in the mindset. But I know, for example, I’ve personally started a post fitting for this Micro Matt blog, and ended up realizing it needed to be a full post destined for my Matt blog. In that case, I’ve switched the publish destination, added a title (required on Matt; elided on Micro Matt), and ended up elaborating on whatever I was writing. So I’m not sure if the distribution context should be intertwined with, or separate from (perhaps in another step), the writing process.
Spending time designing an entirely new UI for Write.as / #WriteFreely today, tailored toward power users. After breaking down jobs-to-be-done and building up an interface from scratch, I’ve arrived at… essentially, WordPress or Ghost or any other CMS. So, how do I plan to make this different?
First: two distinct interfaces, “basic” and “advanced.” This CMS-ish UI would be the “advanced” one, activated only when you indicate you need it, such as when starting a publication rather than a personal blog. By default, users would continue getting a minimalist interface that is centered around writing and distribution, rather than advanced content creation and management. My idea here is that we hopefully don’t lose the plot, and Write.as remains useful as a personal writing / blogging platform. But if I’m rethinking things, I’ll probably want to revamp the “basic” UI users will see by default…
A studio, not a company. When I think about a more grand vision for this overall thing I’m building every day, this is what I feel I want to build. I don’t want to wake up every day and go to the office — I want to go to the studio.
I hear “company” and think suffocating hierarchy and a dull, single-minded focus on profit. I hear “startup” and think underdog stories, empty hype, and forever chasing a carrot on a stick. But I hear “studio” and I think calm, open-ended creation — a place where your work is the goal in and of itself, and not just the means to another end.
This is probably an imperfect term for what I want, but it helps set my priorities straight: build first and the money will follow; work at your own pace; meander as needed; let life intermingle with “work” (in the artistic sense, not the job sense). At this point, all that’s really left to do is to keep creating.
I’m coming to believe that a good digital social space isn’t merely focused on the “social” aspect as we know it today. A commenting platform shouldn't merely offer comments. Social media shouldn't merely enable standardized reactions and call itself “social.” Instead, it needs to offer a social environment, some context, a culture, etc. It needs to view itself as only one part of a whole, instead of all there is. It needs to put individuals' needs above its own (especially its own business model).
If your social platform only enables gathering and “liking” things and replying to other people, it only actually enables a thin band of social activity among the wide spectrum of human interaction. When these anemic relations become the norm on a large scale, of course we start to feel isolated rather than in good company; forever wanting more instead of ever fulfilled.
My old assumption about my “multiple independent but integrated apps” theory was that the apps had to do a ton on their own. I was thinking of it mostly on a technical and individual product level: divide the apps into totally separate packages that don’t really need each other.
This assumption is proving false when I consider the overall suite design on a user level. For example, we have Write.as for writing blog posts and Snap.as for photo hosting — separate apps that work well independently and together. But while this means we can do interesting things on a per-product basis — like photographer profiles exclusive to Snap.as — the separation can be frustrating when you need to use the two together, like when I’m composing a Write.as post and need to insert photos. In that case, I can either switch apps or use the Snap.as browser extension — but this is still too abstract for many users. We need a different level of abstraction.
So I’m working on that now. For example, coming soon to our Classic editor: inline uploads, powered by Snap.as:
I was aiming to have made some progress on Remark.as by this point in 2021, but as tends to happen, other priorities took over — namely, some large migration projects that have spanned several months, some long-standing bugs that have grown too painful, and the continual waves of various SEO spammers from around the world.
I recently shared that the timeline on it is indefinite for now. But the topic got me thinking about it again in spare moments over the last few days. Coming at it fresh, with a “weekend project” state of mind, I came to a new design that basically resembles a link aggregator site like reddit or Hacker News.
This was what I imagined for the “social space” — basically, you head to Remark.as when you’re ready to read comments and shoot the shit with other people. Discussion happens around links back to the original content, rather than hosting the content on Remark.as itself; a close integration with Write.as means we could automatically “post” your articles over there, and we can dynamically link from your blog posts to the discussion, e.g. showing the number of replies you’ve received. Overall, of course, the goal is to keep the social space separate from the composition and publishing space. And I think with this design, for those who want a more social atmosphere, Remark.as would replace Read Write.as as their daily destination.
#remarkas #design #ideas
Yesterday I made some progress on general #WriteFreely maintenance. Reviewed some pull requests, added some quick fixes, and moved the repo on GitHub, as announced. I also figured out what was causing the “availability issue” — just some too-tight restrictions we recently placed on the API.