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

Thoughts? Discuss...

Thoughts? Discuss...

• 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

Thoughts? Discuss...

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

Thoughts? Discuss...

From a data perspective, these are distinct objects with a one-to-one relationship. A Member is (aside: always backed by one User, and) always associated with one Author — but an Author can exist without an associated Member (if the Member was removed from the team, the User was deleted, or it’s an outside collaborator).

From a user management perspective, team admins will always interact with either a Member-Author or just an Author object. But the complexity will be hidden and they’ll look the same to the end user — just in different states, really.

From a user (writer) perspective, a team writer will always interact with an Author object. They’ll only be concerned with who is authoring a post.

#dev #teams #authors

Thoughts? Discuss...

#dev #teams #authors

Thoughts? Discuss...

Now, there are three “person” concepts in Write.as: User, Team Member, and Author. The first two, User and Member, are private structures that primarily hold permission data and contextual settings (User: password + email for the platform; Member: role + email for the team).

An Author, however, is a public structure meant to hold publicly-known information, like a bio and post authorship. Most blogging platforms don’t make the distinction between an Author and a User like this. But this allows us to minimize data collection and eliminate unnecessary work for writers (a single-user blog doesn’t really need an author bio, because the blog is the bio).

I often think of our UX like various gentle slopes of increasing friction and weight — from simplicity to complexity, or zero to full data collection. With this new user structure, we can maintain a gentle slope from writing alone to writing with others. The experience for a single blog author doesn’t change at all — the added work only shows up at the precise moment someone decides they want to write with others, and specifically, that they want some kind of public authorship known to readers (that is, we’ll still enable you to have a multi-author blog that conceals the identity of individual writers).

#dev #teams #ux

Thoughts? Discuss...