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 ofuserpics 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:
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
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:
- They wanted to support the service - OK, this reason does equally apply to the Dreamwidth;
- 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;
- Free users only had 3 userpics, and that not a lot. Dreamwidth gives 6.
- Free users could not customize styles, but rather only select from few pre-defined ones. Dreamwidth never mentions "styles" in the comparison table;
- 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;
- Ability to use "short" journal name like <user>.livejournal.com; this is now a default address in both Livejournal and Dreamwidth.
- Ads-free access to Livejournal; this is not applicable to Dreamwidth;
- Bigger and ads-free photo hosting; Dreamwidth is unclear on this;
- Styles (reason #4 above)..
no subject
Actually, I think you underestimate the desire for icons. Look how many people go into news post after news post demanding more icons, and how the extra icons add-on was popular enough for LJ to even code in the option. Icons are probably one of the top reasons people buy accounts.
no subject
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.)
no subject
For example, will free users get some, even if small, photo hosting quote, or nothing at all?
no subject
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.
no subject
I think some RPG communities and some other specialised uses want more than 1000 tags, though obviously this will be a small proportion of the userbase.
Editing comments and getting emailed your own comments is worth $25 a year for me, even without the userpics. I think "Premium Paid" is aimed a lot more at those who do want to support the site financially as well, hence the larger jump in price. Also userpics cost disproportionately more compared to other paid benefits.
no subject
One problem with "editing comment" (in LJ, anyway) and the reason I almost never used this feature in LJ is that edited comment gets sent again to the author(s) of the post and parent comment, and that looks weird on a receiving end in my opinion, to get two almost identical e-mails where the only difference is in a couple of letters (especially given that participating in a heated discussion may result in dozens of e-mails in a rapid sequence) But perhaps, no one else cares about that, I wouldn't know.
editing comments
i am not sure how one can avoid the multiple emails. one way would be to only allow the editing for a limited number of seconds, such as some forum software does, and only send the email at the end of that time. but that is only useful for people who see typos right after they posted, not for people who actually had additional thoughts. or for those who see the typos on their next visit to the post. i don't know whether there is a good solution.
Re: editing comments
Why are these e-mails being sent? Basically for two reasons: (1) prevent abuse (2) make someone who is replying to comment know about the changes, possibly relevant to his reply.
Second reason is immaterial in my opinion. If your change is important enough, as opposed to merely HTML formatting or typo, better submit another comment.
As for abuse - there isn't and could not be universal technical solution to prevent any imaginable type of abuse. As a similar example, let's consider how moderated communities work. When you submit your post, it won't appear until a moderator approves it, but afterwards you can edit it any way you want. It is assumed that this feature must not be abused, or you risk being banned from the community.
Same applies here; if someone thinks unlimited comment editing is too dangerous, then let's give journal and community owners option to either subscribe to these e-mails (but, even if enabled, this wouldn't trigger e-mail notification to the author of the parent post, only to journal owner), or simply disable comment editing in his journal/community altogether.
yes, we will see
you underestimate several things:
"some" people on LJ like icons -- "some" is a number in the tens of thousands. same for highly customized styles. this is a major attraction -- it still boggles my mind, but there it is.
the tag limit on LJ was instituted because quite a number of people (and comms especially) slowed the servers down because they had so many tags. well-organized comms, such as
you and i may be able to throw together a quick script for anything we want to do, but the vast majority of users can't. they like their bells and whistles, and they like them served up pretty.
localization might come later; the groundwork is being laid now. i think it is a good idea to put it off, because LJ's translation system is a mess. if you end up finding some free time and joining the effort you'll get to see the code intimately up close -- might as well brace yourself now. :)
photo hosting is on the list of things to come within the year.
in any case, welcome to dreamwidth, and i hope you enjoy it here!
no subject
Regarding "post by e-mail" option, I guess what I meant to say is that just about any imaginable usage of that feature (such as posting from mobile phones, etc.) could be better solved with specialized software client (like LJ client(s) for iPhone) based on published interface. After all, if you can run a e-mail client, you can also run an LJ client, can't you?
And icons, yes.... I have so far used 4 in my "permanent" LJ account - out of 197 available - but I guess it's just me :)
translation and icons
ah, that's what you meant about "post-by-email" -- yes, possibly so. i haven't thought about it much. i've never even used it outside of testing. i just know that apparently lots of people like it.
icons, *heh*. i had an LJ for more than a year and only used 1 icon. when i got a paid account, it was to support the site; i didn't use more than 6 icons. now i have nearly 50 that i made myself -- and i still don't use them often, only when i really want to underline a specific point, or express my association with a specific group. generally i like the single "avatar" association. but i know i am in a minority. and the site needs to serve all of us, and deliver for a wide variety of tastes.
Re: translation and icons
One thing about LJ is that in many ways it is built around technologies and ideas from the 90's. Times changed, and nowadays many web sites offer "translations" implemented with some machine translation tools. For example, our local MBTA site can be viewed in 14 languages, and they very openly warn visitors that "the translation is literal and may misrepresent names and idiomatic expressions", but still, people do it for a reason.
Similarly, old LJ translation could be perhaps augmented with Google translation, so that you wouldn't see a weird mix of languages as you do today.
That's just one example, I am sure many other technologies could be used here which simply didn't exist in '99.
no subject
ETA: fix markup
no subject
This is Web 2.0 we are talking about, aren't we?
no subject
The other thing you're not considering is, Denise and Mark think they can build a sustainable business with people who are willing to use the site in English. In addition, the language translation was never good on LJ except for 2 or 3 of the most popular languages, and even those hovered at around 85% of documents translated, (that is to say, a translation existed of any version of a page, not necessarily the current version.)
The LJ approach to translation was, tbh, a lie. Just looking at how many pages our docs team had to English-strip (that is to say, rewrite the pages so that it was technologically possible to translate them) shows that in many, many, many places, LJ wasn't even pretending to translate.