Dreamwidth Business Discussion

Scheduled/Draft Posts

Now that we've finished the first draft of site search, our next major project is going to be scheduled/draft posts, which are two separate concepts that we've been bundling together since it'll likely be easiest to do them together:

* The ability to save entries midway through writing them, on our servers, as a draft that you can come back to later from any computer;

* The ability to write an entry and schedule it for posting sometime in the future, either once ("post this next Wednesday at 9PM") or recurring ("post this every Monday at noon").

We have specs for both scheduled posts and draft posts in Bugzilla, but we also wanted to throw it open to the crowd for discussion in case anyone has some awesome ideas we haven't thought of:

* What would you want to see a system like this do?

* What would make you want to use it, and what would be the "killer app" for you?

Update Page

Part of this project is also going to involve redesigning the Update page.

We want to make it possible for you to access your scheduled and draft posts at the time of update, in order to work with them, as well as giving us room to add more options in the future. The existing page doesn't have a lot of leeway for us to add new things, and some of the things we've added since we branched from LiveJournal don't integrate very well.

The resulting Update page after the redesign is likely going to be considerably different than what it is right now. (For instance, I'm tentatively thinking about folding in some of the functions of the Edit Journal Entries page, turning the update page into more of a dashboard, where you can access all of your recent posts -- published and unpublished -- along with your publishing schedule, and then edit or reschedule them, or create a new post -- but that's just a very vague idea.) There's also a lot of things we can do for that page, accessibility-wise, to make it easier for people who use assisitive technology.

We don't want to make things worse from a usability standpoint, though, since writing entries is one of the core functions of the site! Mark has done some statistics about which options are most frequently used while posting, which we'll be taking into account, but I also wanted to ask for thoughts:

* The four most-used options at the time of posting, from our data, are: icon, mood, tags, and crossposting. If you consider something else (other than those four) absolutely critical to how you use the update page, what is it?

* What's one major thing you always wanted to change about the current Update page, and why?

* What are the things you've always liked about the current Update page, and why?

We'll use your opinions to come up with the next iteration of the Update page, which will probably go through several revisions until we come up with something that we (and you!) are satisfied with.

(RFC: "Request for comment" for peer review in Internet terms, and how we'll be developing our policies. We'll post things to dw_biz tagged "request for comment", leave the commenting open for a period, and then integrate your comments and feedback into whatever policy we're developing. Most policies will go through several rounds of RFC.)

So, part of what I want to do is make sure that we have a very clear commenting policy for Dreamwidth "official journals" (anything that starts with dw_*) and that we enforce it from the beginning, in order to be consistent in our moderation. We'd like for our official journals to be places where people can feel comfortable bringing issues to our attention, providing feedback, and asking questions, without having to worry that they'll be attacked or derided by someone else. At the same time, we want to be as clear as possible about what we will and won't moderate, so people who are commenting know what we expect of them.

We want the comments to our official journals to be useful, on-topic, and relevant, whether ultimately positive or negative towards the project. In particular, we want to make it very clear that disagreeing with other people, raising objections, criticizing mark and me, or pointing out problems is perfectly okay, while at the same time making it clear that ad hominem attacks, treating others with hostility or malice, telling other people that their comments aren't productive/contributing to the discussion, telling others things like "cry moar", and comments that derail the discussion without contributing anything of substance (so, like, pages and pages of cat macros) will be screened and may result in the commenter being banned.

What sort of things do you guys think a commenting policy like that would require to be spelled out, and what can be taken as understood? I want to avoid saying things like "treat others with civility", because "civility" is a term that varies from culture to culture, but I also want to get this sort of commenting policy into place as early as possible, while our "early adopters" are people who come to the project with good faith and a desire to build a productive community, so that things are ingrained in the culture from moment one.

I have a vision about the sort of thing I'd like for the policy to contain, but I'd like to get feedback and suggestions from you guys first, before I attempt a draft of it. (Once I do, I'll post it here for people to go over and suggest improvements.)

Because we are committed to maintaining a stable, reliable service without ever accepting third-party advertising, we rely on subscription fees from our users to help us meet our operating costs. In exchange for those subscription fees, we offer additional or expanded services and features to our paid users as a way of saying thank-you for subsidizing the service for everyone else. We also reserve the features that cost us money to offer, or that cause significant database or webserver load, for users who have purchased paid accounts.

All of our assumptions, spreadsheets, cost projections, and business plans were done at a 5% paid account rate: each paid account will subsidize 19 free accounts. This applies whether the paid account is for a month or a year. Every payment someone makes will help pay for our servers, our bandwidth, necessary professional services, and the salaries and contractor payments we will be making to those who help develop and run the site.

We project that it will cost us approximately $1.40 a year to support each active user.

Features are reserved for paid contributors for two reasons:

1. Because offering the feature costs us more than a few cents per user per year;
   
2. As a way of saying "thank you" to users who have chosen to support the site, and other users, financially.

This means that some features are reserved for paid users because they're expensive, and some features are reserved for paid users because they're popular. (Sometimes, it's both.) For features that have limits, we offer higher limits to those who choose the Premium Paid account level. This reflects the fact that offering higher levels of these features costs us more money.

As we create new features, we plan on doing it two ways. Some features will be entirely reserved for paid users. Some features will be available to everyone, but significantly enhanced for paid users. We want to strike the right balance between rewarding people who've chosen to subsidize the service for everyone else, and making the service useful and functional for members of all levels.

We know that we likely won't get it completely right on the first try, especially since many of the paid user features on LiveJournal.com aren't available to us to use (either because LiveJournal's implementation of the feature isn't Open Source, because offering that feature would require expensive external partnerships, or because we don't think the implementation LiveJournal chose was the best way of doing it). During our first year of operations, we will constantly examine the paid user features and see what we can add.

Here's a list of the paid user features that will be present at open beta launch (along with why they're a paid user feature). Right now, you can see the Account Levels wiki page; we'll move that information onto the site before we launch to open beta, as we get our payment system finished.
( Paid user features at launch )

There are two things that LiveJournal reserves for paid users that we allow every personal account (ie, not OpenID accounts) to do, because we think they're such critical and useful functions of the site that all users should be able to do them. Those things are:
( Things available to all users )

In our first year of operations, we'll be adding a number of features that are either paid-user-specific, or are significantly enhanced for paid users. Right now, the plan includes any or all of the following:
( Coming Soon! )

Welcome to dw_biz, where we'll make regular posts about the business operations of Dreamwidth Studios, LLC, the company that runs dreamwidth.org. We'll use this to talk about the reasoning behind our business decisions, tell you about what we're doing, answer your questions about our operations, and generally keep you informed.

Posting to dw_biz will be limited to Dreamwidth's owners and staff, but anyone can subscribe to the community and make comments to posts.

For our inaugural post, I figured I'd provide answers to some of the common questions we've been hearing. (Many of these questions and answers come from the Business FAQs list that we kept on the Wiki up until now, but I wanted to move them into dw_biz for posterity's sake.)

( Operating Structure )
( Account Types and Costs )
( Feature Design )
( Site Content )
( Overall Site Questions )