One tricky thing: do we track which #categories are included in the post itself vs. in pure metadata?

Assuming all are inline, things are simple: on publish or update, we always parse hashtags in the body. If a tag isn’t there, we delete its association with the post. If it is there, we associate it with the post.

If we also want to have pure-metadata categories, so we don’t have to clutter up a post with visible hashtags, then we need to track which categories are inline vs. metadata-only, so we know which ones to remove on update and which ones to keep. (And now this is getting complicated.)

It’s mostly getting complicated in the UI. Assuming the editor now has a “categories” field, we’ll need to keep it in sync between inline / editor hashtags and metadata-only tags. I mean, it’s unlikely someone would use both; I don’t want to cater to that edge case, but I also don’t want to exclude it if we don’t have to.

We might also follow the pattern we’ve laid out with other add-on post metadata, like #authors. Right now, you can add an author in the Rich Text (RT) editor, but not the Plain Text (PT) editor. In this way, we keep our underlying flexibility, but the client / editing UI guides users toward the correct input method. I think we can assume that the PT editor is for focused writing and inline metadata; the RT editor is for exact control over presentation and metadata. I’m not sure if that’s entirely correct, but I think I have to start there.

#dev

Thoughts? Discuss...

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

Thoughts? Discuss...

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

Thoughts? Discuss...

I’ve had a lot of trouble modeling the Team Member / Author roles I recently came up with to support everything we need to on collaborative blogs. Unlike Users, Posts, and Collections (blogs) that I can understand from one perspective, these new concepts need several perspectives to fully understand (and model correctly). At this point, I think I’ve finally worked it all out:

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...

Author functionality is coming along! Now it’ll optionally display at the top of a post, if it has one or more authors set.

#dev #teams #authors

Thoughts? Discuss...