First post

[ign]

Many thanks to the kind developers and testers of the Dreamwidth, I've got my "invite code" and is finally able to reserve my favorite username!

Overall, this does seem like a very nice job porting basic Livejournal features and UI (I regret that being a programmer, I didn't have sufficient free time to contribute, but perhaps I will) while making it easy to use and more consistent in the process.

I regret though that development team has decided against making localized UI version available (I believe that this capability has substantially contributed to Livejournal original success, especially in non-English-speaking communities). Yes, making any sort of user-provided content publicly available as site UI can and will backfire, but it is important to strike a right balance.

What I don't really understand is how business managers are planning to attract paid-account users in any substantial numbers. Comparison table between different account levels does not give any incentive whatsoever to ever want to upgrade to paid account, other than an obvious desire to support a good work by dedicated people. Who the hell would need more than 1000 tags, anyway (other than some automated publishing system, but that's a totally different issue)? Or, let's say, post via e-mail - I can trivially write a script which would make it possible via XML-RPC, should I ever need it, but I never used this option with Livejournal and not going to.

OK, granted, some people love dozens of userpics user icons and possibility to edit your comments is nice, but I am not sure how this could justify $25 per year.

That said though, "premium paid" account is a total mystery to me. 2000 tags instead of 1500 for twice the money? Well....

Speaking of Livejournal, historically in the early days of the service paid accounts attracted people because:

1. They wanted to support the service - OK, this reason does equally apply to the Dreamwidth;
2. This was the only way to get an invite code, and this way people who would not otherwise consider this were lured into paying - OK, Dreamwidth does use invite codes;
3. Free users only had 3 userpics, and that not a lot. Dreamwidth gives 6.
4. Free users could not customize styles, but rather only select from few pre-defined ones. Dreamwidth never mentions "styles" in the comparison table;
5. Livejournal also promised faster access to paid users, not that I think it ever delivered, but still, it sounded nice. Dreamwidth does not mention anything similar to that;
6. Ability to use "short" journal name like <user>.livejournal.com; this is now a default address in both Livejournal and Dreamwidth.

Currently, Livejournal users purchase paid accounts because of:

1. Ads-free access to Livejournal; this is not applicable to Dreamwidth;
2. Bigger and ads-free photo hosting; Dreamwidth is unclear on this;
3. Styles (reason #4 above)..

Anyway, I sure hope this new platform and community will succeed and attract attention beyond some dissatisfied LJ users, but we will see.

Comments

[denise]

This.

Paid users will have the "jump the server queue" thing here, too, and there'll be some styles and themes that are only available to paid users, and there are a bunch of other little tiny paid user features, but the overwhelming #1 reason people paid for their accounts on LJ was more icons. (Well, until ads came along.)

When we were designing our account levels, we erred on the side of giving more things to free users in a bunch of places, because we thought they were silly to have as paid features or because they were part of what we wanted to include in the site culture (for instance, all users can create syndicated feeds, because we want to be really interoperable with other sites). We do have one paid user feature that LJ doesn't -- Google Analytics integration -- that isn't on the comparison on the Wiki yet (but will be on the site by open beta launch), and many of the features we develop in our first year will be paid account features or significantly enhanced for paid users. But for the first few months at least, the major reasons to pay for an account will be to support the project and icons.

(Photo hosting -- we don't have it yet, but we're hoping to get it done by the end of this year or around the beginning of next year. LiveJournal's photo hosting is both an administrative and usability nightmare.)

[ign]

May thanks for clarification, Denise. This way it makes more sense, but still if I were you I would have spelled out photo hosting specs now (by open beta that is), even if actual implementation is still long way ahead and specs are very preliminary.

For example, will free users get some, even if small, photo hosting quote, or nothing at all?

[denise]

We don't know yet! That's why we haven't said anything -- the specs are still totally up in the air, and will depend on what a). the community wants and b). we think we can support. So, we'll have to look at the traffic and usage patterns, along with the paid account percentages, and see what kind of stuff we can deliver. I can pretty comfortably say that we won't be able to offer it until we move from dedicated-server hosting (we're with Slicehost right now) to colocation, which we hope to be able to do quickly, but we don't have a firm date on.

The reason we haven't specced photo hosting yet is because we actually want to use that as our first example of how we're going to design major changes or major new features. The way it will work will be:

* We post somewhere outlining the broad summary of the project -- "We want to add photo hosting" -- and ask the community what they would want to see in that feature, what they would find really useful, what they would find not useful, etc;

* We take all of that feedback and design a functional spec, then post it and say "here's the spec; what are we missing, what did we get wrong, what do you really love?"

* We take that feedback and revise the spec, incorporating what we can and explaining why we can't/won't incorporate the rest;

* We turn the spec over to whoever will be doing the frontend design and have them do mockups of the pages involved;

* We post those, and ask people "okay, what do you find confusing about this, what do you hate, what do you think would be hard to use," etc;

* We revise the mockups based on that feedback, incorporating what we can and explaining why we can't/won't incorporate the rest;

* We turn specs & mockups over to the programmer who'll be working on it.

That's the right balance between incorporating user feedback and the hell of something that is designed-by-committee, I think. We won't be including everything that everyone wants, because many bits of feedback will be mutually exclusive, but we need to be able to at least explain why we won't include something, or justify our choices for which of the two mutually exclusive options we pick.