Micro Matt

Micro thoughts and mini posts.

Working on support for categories today. There are a few functional goals we’re trying to solve with this:

  • We can list all categories used on a blog
  • We can quickly filter all posts under a certain category
  • We can create tags with specific capitalization, Unicode characters, and spaces in the name
  • We can associate posts with certain categories via existing plain text tagging system

The last point in particular is pretty tricky to solve; all other points are solved easily by adding some new data structures. I’m thinking we’ll just store three pieces of data for each category: a slug (e.g. united-states), a title (e.g. United States), and a normalized “lookup slug” that can be represented by a hashtag (e.g. unitedstates).

Then we’ll do some magic on the backend when creating or updating a post that parses the post and creates a new category automatically and / or associates the post with an existing category. That will allow existing posts to use this new categorization system. Then we might also support a new “silent” way of adding categories via a new API field, so you can associate a post with a category without inserting it into the body of the post.

Just some implementation ideas so far; we’ll see if this works in practice.

#dev #categories

Woke up to sub-70° air outside and I instantly feel better, like I can relax and finally breathe again. Endless summers have done nothing good for my mind. For some reason I crave a long winter, gray skies and cold.

After a chat this morning with the writer behind Minimalist EdTech, and now reading Jake LaCaze’s most recent post — hearing Chuck Palahnuik’s “writing vs. typing” distinction he to linked from that post — I’m struck by a clear new principle for the software I build:

The tool is subservient to the voice it carries.

I think it’s easy for tech folks to get carried away building and adding and expanding their digital creations until it’s everything to everyone. We get fascinated more by the workings of the machine than the people working it. We force our specific way of working on the people that use our tools. We focus on how our little widget will revolutionize whatever it’s revolutionizing, and along the way lose the point of why we even need it to begin with.

This new principle is suddenly so clear to me now. The tech is so trivial and insignificant compared to whatever human thing it enables. We spend so much time thinking about the technical side while neglecting what our tool actually does for people. The product only needs to do what it set out to do. The code only needs to be elegant enough to be maintained — anything beyond that is pure onanism.

People will always find a way to write, learn, and socialize, with or without the latest technology. As builders of this digital world, we need to wave away any grander illusions than that. If we want to build things that actually improve the world instead of creating more pointless problems, we need to remember that it isn’t about the tool, but the people that use it.

#tools #humanity #tech

One cool thing about our platform today is that I’m finally getting to benefit from code and component reuse. In just a couple hours, I can create an entirely new service backed by Write.as, with user authentication, billing, data sharing, and a standard API design.

As I add Remark.as, Draft.as, and today’s new (yet to be announced) service, I only have to follow a set of patterns and interfaces I’ve already built to hook into user authentication and create the web UI — altogether it only takes about 15 minutes to do. Then I’m on to building the actual functionality of the new service.

There’s something about the strange loop of “building tools that help you build tools” that is very, very satisfying.

Just rolled out the largest update to Write.as I’ve pushed in a while. Most regular users shouldn’t notice anything different, but Team users will see it: a way to switch the entire interface / navigation from your personal Write.as account to your Team (as I’ve written about before).

These changes stretch across to the management side of the app, but it was all mainly for one reason: knowing what information to present in the editor. The “action context” (as I’ve called it internally) dictates what integrations the editor presents, tells photos where to go when uploaded from the editor, and determines what authors you can publish an article under (this feature is coming next). Since I was working in the editor anyway, I also made those other small updates announced today.

I probably could’ve designed this in a different way, especially to fit my fluid usage (tens of personal blogs, plus three teams, each with many blogs). But from an actual customer perspective — the people I’m building this for — I think the firm line between “individual writer” and “team member” is the right way to go. Plenty of people will only be writing for their team, for example. Hopefully this design fits them well (besides my own dogfooding, we’ll find out soon with early testers).

Next, as I mentioned, we’ll launch those author features. I’ll announce that more widely on the official blog.

#dev #teams

My thinking lately has started drifting to businesses outside of my own.

This “main street” idea is particularly interesting to me, because I think it’s the start of a path that can actually lead to meaningful resistance against the tech-giant-dominated web we live on.

I still dream of the early web days, with less rampant commercialism and more free-flowing humanity and knowledge. That side of the web is still alive and well, and will always be around. But it feels pushed to the fringes, and left out of all the mainstream conversations on today’s privacy violations, “misinformation,” and social ailments caused by the “big web.” I think it’s all pretty ironic when this old, human web holds solutions to all these problems. The answer is right in front of our faces, yet we blindly look past it.

I’m not sure what this all looks like in practice. Somewhere in it, maybe, there are organizations providing funding for small businesses that need it. Perhaps there’s a curated, social marketplace only for small businesses, where everyone in it can get to know each other. Or a federated network of these independent bazaars, naturally powered by communal, open source software. Just thoughts for now.

#web #business #mainStreet

Implemented the Write.as context switching system! It shares a bit of plumbing and UX with the Snap.as system, but diverges otherwise, since we have a /me/ base path for all “personal account” screens and an /org/ base path for all team-related screens. That means we don’t need as much state-tracking here, unlike on Snap.as.

Overall, the team-based navigation feels a lot cleaner to me (though I still need to get used to it). Here’s what it looked like before, where you’re always acting as the user and really just “visiting” teams you’re a part of (note the top navigation bar that mixes personal sections with your team):

Here is the new layout, with a pared-down context menu that allows you to switch back to working in a personal capacity:

Some notes:

  • All those extra pages (Profile, Integrations, Billing) have been moved under the Settings section (though I guess moving them to the context menu dropdown would keep things consistent.)
  • I haven’t settled on the “Dashboard” terminology, though it might be helpful to show helpful things from across the suite here — new submissions, new comments, etc.
  • When we support shared drafts for teams, I imagine adding a Posts section to the top navigation

Starting on user / org context switching today, so I can finish up our support for outside #contributors on #teams. Excited to get this big new feature out the door!

Realized that we need a clearer line, UX-wise, between the personal writing experience and Team writing experience.

  • Teams basically act as Users, with their own set of integrations, Snap.as uploads, drafts (eventually), and a pool of #authors that they can add to blog posts
  • We want to severely reduce the chance of accidental posting to the wrong blog (don’t want a personal post ending up on the company blog!)
  • We can optimize the editor and backend management flow if we know you’re in “team mode” instead of “individual writer mode” — like working at the office vs. writing at home

Concretely, we’ll have a way for users to switch between their personal account and any team they’re a member of, like they already can on Snap.as.

This also furthers my assumption that collaborative work on our platform is different from writing as an individual — something I don’t think many publishing platforms assume. With time, we’ll see how that assumption holds up, or if the improved Team UX / navigation bleeds back into the individual experience.

#teams #dev

Yesterday I made a ton of progress on new Team features. The biggest one is the ability to add outside contributors, so you can show authorship information on posts without actually creating accounts for each author.

Besides that, I updated the Snap.as API to support Team uploads, and updated the Classic editor to do the same — so if you have a Team blog selected in the editor, your photos will automatically upload to your Team’s collective photo storage, instead of your personal account’s storage space.

These features should go live today or tomorrow!

#dev #teams #authors #contributors

Enter your email to subscribe to updates.