denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
Denise ([staff profile] denise) wrote in [site community profile] dw_biz2012-02-13 03:45 pm

feature design brainstorming: icon add-ons

We said last month that [staff profile] mark's next big project is going to be icon add-on packs to let people buy more icon slots if they want, and this week he and I have been brainstorming ideas to make it work in the quickest, easiest, and most usable fashion. This is what we're currently thinking the system will look like, for you guys to mull over and point out all the things we've no doubt forgotten to think about. ;)

Goal: To let people buy as many icon slots as they want (up to whatever limit we impose for overall performance reasons), as simply and easily as possible.



We started out with the idea that this should be something the user can decide (how many slots you want), not sold in pre-specified numbers of icon packs that stack on top of each other. We kicked around a few ideas for a while of how to make that work (such as paying per icon slot per month, etc), but everything we tried to come up with got really confusing very quickly: we would have had to track a lot of different things, and explaining pro-rating to people is really hard, and it would've been really hard to add more icons later if you decided you didn't have enough.

So, our current working theory: we will charge you up front for each icon slot you want to add, and paying for another icon slot will give you that slot permanently, for whenever you have a paid account. (We have a vague idea of what each slot will cost, but it's not set in stone yet, so I don't want to commit to anything; I'll use the variable $amount while I'm explaining, in order to avoid making any promises.) If your paid account expires, you'll go back to the number of icons a free account gets; if you renew your paid account, you'll go back up to the paid account icons + your add-ons.

It's probably easiest to talk through some practical examples of common scenarios, so everyone's on the same page: let's say that I have a premium paid account, so I have 250 icons. I want 270 icons. I pay $amount to permanently buy those 20 icons; my icon slots go from 250 to 270. In a year, my premium paid time is about to expire, so I renew it for another year; I only have to pay the $50 to renew the premium paid time, and my icon slots stays at 270, not the 250 a premium paid account usually gets, because I bought those 20 icons permanently.

Next year, my premium paid account expires (back down to 15 icons, curses!), and I'm kind of low on cash, so I decide to renew it as a regular paid account ($35 for the year; 100 icons), not a premium paid account. But! I previously bought those 20 extra icon slots. Those still exist, but they're applied to the paid account icon limit (100 icons), not the premium paid account icon limit (250 icons): I'd have the 100 icon slots a paid account usually gets, plus the 20 I permanently bought, for 120 icons.

After a few months, though, I decide I can't live with only 120 icons, and I decide to buy some more. I pay $amount to permanently buy another 50 icon slots. My new icon count is now 170: the 100 for a paid account, the 20 I previously bought, and the 50 I just bought.

When account renewal comes around, I decide I miss the premium paid account benefits, so I renew as premium paid ($50 for the year; 250 icons). I now have the 250 icon slots that come standard with a premium paid account, plus the 20 I bought a long time ago, plus the 50 I bought recently, for a total of 320 icons.

So, you're only buying the icon slots once, and they last forever -- but, you have to have a paid account to access them. (This is to avoid people buying just icon slots, which is bad for us from a business standpoint based on how we set our account limits. For an explanation of why you won't be able to just buy icons without a paid account, see two old mailing list messages I wrote back when we were in development: #1, which explains why you can't buy paid features a-la-carte, and #2, which specifically gets into icons.)

We'll be pricing icon slots based on the cost to support them over time, so you'd pay more up-front than you would in a yearly, expiring type deal. You'll never have to pay again, though, so it will be cheaper in the long run.

What if you want to switch to using a different account, though, the way we know roleplayers like to do? You'd be stuck paying the up-front cost over and over again for each account, which would not be very fair! So, instead we make it possible for you to switch icon slots from account to account.

Let's say I have two accounts, [profile] x and [profile] y. [profile] x is a premium paid account (250 icons) and I bought 50 extra icon slots for it over time (total of 300 icons). [profile] y is a paid account (100 icons). I decide I want to stop using [profile] x and switch to using [profile] y instead: I can go to the icon slot mover tool and say "switch my extra icon slots", and move the 50 extra slots from [profile] x to [profile] y. Now [profile] x has 250 icon slots (the standard with the premium paid account), and [profile] y has 150 icon slots (the standard 100 with the paid account + my 50 extra slots that I bought).

(We may charge a small amount to move icon slots from one account to another, especially if it's been a while since you bought them, like the way we charge for a rename token. But we haven't decided that yet; it will depend on what the numbers look like when we diagram the costs of all this out more fully.)

There will be a limit on how many slots you can buy at first -- this is because the system isn't very optimized for large numbers of icons, either for resource usage or for the user interface of displaying and selecting large numbers of icons. (We can fix that over time, and we will! But that will take time, and we'd rather release the feature with a lower limit now than wait. Whatever limit we pick when we release it will almost certainly be raised later once we can do the work.) It's also possible that we might have two limits, and charge $amount for each slot up to limit #1, and $amount*2 for each slot from limit #1 to limit #2, but that, too, will be up in the air until we can really plot out the technical and business details of this way of doing things.

So, if this is all still up in the air, why am I posting about it now? Simple: We know that we can't know everything about how people use their accounts and how people want to use their icons. So, consider this the open invitation to pick holes in this plan: what kind of usage are we forgetting to think about/account for? What problems do you see?

(Also, because I know a lot of people are really sweet about worrying what this will mean for us-as-a-business: we already did all the back-of-the-envelope feasability tests, and this should remain feasable over time. We're gambling that the cost of disk space, bandwidth, and processor power will continue to go down over time the way it's been going, historically, so the pay-once model for icons should work fine for us -- and because it will be tied to paid accounts we won't be promising future services without any additional income the way we would for seed accounts.)
algeh: (hmm)

[personal profile] algeh 2012-02-13 10:22 pm (UTC)(link)
Having through about it slightly more, here's a dynamic that you may not have considered (I'm not sure how it actually affects your calculations, but it's worth thinking about if you haven't):

"Gifting" icon slots around between users. For example, [user 1] posts "I'm going to let my paid account lapse because reasons. Who wants my extra icon slots, since I won't be using them anymore?" [user 2], who has a paid account and likes free stuff, steps up and asks for them, and the slots are transferred to [user 2]'s account.

In and of itself, this may or may not be an issue you've already thought of, but it also creates two new additional sources of headaches that may be less obvious:

- [user 1] buys a paid account again in a year and wants [user 2] to give them back their icon slots. [user 2] either doesn't want to, or, if implemented as upthread where you can't transfer partial amounts of slots, may be unable to due to having also bought other slots. Anger ensues. Presuambly, this can be solved by making it officially Not DW's Problem, but it's worth being aware of.

- [user 1], rather than gifting the slots to [user 2], sells them to [user 2] for less than the cost they'd be to buy originally. [user 1] is happy because they got money for something they aren't able to use anyway, [user 2] is happy because they got a discount, but it creates problems for Dreamwidth since people would presumably look for icons on this "secondary market" before buying directly from DW and thus throw off the cost projections, and also because, no matter what kind of DON'T DO THIS NO REALLY policy DW has in place, users would still get defrauded and then complain to DW when someone didn't follow through with transferring the slots they'd "paid" for.
tameiki: (Default)

[personal profile] tameiki 2012-02-14 03:01 am (UTC)(link)
But you could "gift" extra icon space from the original page like we can paid time, right?

Even though I'm only using 28 of my seed 250 and not likely to need/want more, I think this is a great idea! Gifting icon space via buying icon points would be perfect for some of my friends :)

Egads! But I love how you guys ask for your userbase's opinions and talk to us like this. *huggles hard*
Edited (Had to correct a singular "friend" to a plural "friends". Luckily I have more than one. XDDD) 2012-02-14 03:03 (UTC)
tameiki: (Bleach - Nova <3)

[personal profile] tameiki 2012-02-14 03:18 am (UTC)(link)
*bounces* That would be SO great! *squees*

^_____________^



triadruid: Apollo and the Raven, c. 480 BC , Pistoxenus Painter  (Default)

[personal profile] triadruid 2012-02-14 07:40 pm (UTC)(link)
That seems totally fair.
green_knight: (Anglerfish)

[personal profile] green_knight 2012-02-14 08:07 pm (UTC)(link)
It seems to me that DW already has the concept of a master account (I believe this came up in regard to import or communities), so the icon thing would extend that - you can transfer between your own accounts but not to somebody else.

(edited to remove superfluousity - I see it's transfer between paid only anyway)
Edited 2012-02-14 20:17 (UTC)
slays: (Default)

[personal profile] slays 2012-02-14 09:40 pm (UTC)(link)
This same email address would be really inconvenient for some people who use gmail labeling for their RP journals, because it requires email specification for each specific journal. I.e.,

My personal journal:
live.infamy@gmail.com

Buffy's journal:
live.infamy+slay@gmail.com

Damon's journal:
live.infamy+compels@gmail.com

Etc., etc.

These show up as different emails for your server even though they go to the same place (I know this because when I try and retrieve my lost usernames, I have to use these specific filters individually). So, would I be able to temporarily change my e-mail to live.infamy@gmail.com to make it function (which, if that works, people could just ... change their e-mail accounts/passwords/etc. for gifting icon slots between other people's accounts also) while I swapped over my icon slots, or would I just be screwed due to registering an account with a +specifier email?

/more to think about.

That said, I DO really love this icon slot transfer idea because so many times I would mourn the loss of my loyalty pics with LJ when I changed characters/journals/etc. It was the most depressing thing in the universe, so this way I'd be able to keep them through transfer, which is glorious. ;_; So, thank you, guys!
slays: (Default)

[personal profile] slays 2012-02-14 10:09 pm (UTC)(link)
SOBS I'M SORRY, we make life complicated, I know. Thank you for trying to/wanting to look into accommodating it. ;_;

Honestly I am just relieved to know it is a thing you're aware of and interested in accommodating laejklaejg DENISE, I CAN'T HANDLE THIS KIND OF CUSTOMER SERVIE, OKAY, IT'S TOO MUCH. CULTURE SHOCK. STOP BEING SO HELPFUL AND RESPONSIVE. I do not know a single company, online or otherwise, that's as aware and interested in customer support as you guys, man.
thorfinn: <user name="seedy_girl"> and <user name="thorfinn"> (Default)

Anything Can Happen

[personal profile] thorfinn 2012-02-15 02:30 am (UTC)(link)
You can't accommodate the + in email accounts that way. The left-hand-side of an email address is standards defined as being capable of being anything. Literally, anything. Not even just ascii limited.

What the LHS of the email does when someone tries to deliver to it is entirely up to the configuration of the server receiving the email. + is merely a "commonly used" standard, but is by no means necessarily meaningful in any way whatsoever... and you cannot tell whether it's meaningful except by actually trying to deliver email. And even then, you don't have useful information - servers can and will accept email for non-existing LHS addresses and quietly file in the bitbucket.

If you want to stick to email, you can have separate "owner email" and "contact email" addresses, thus allowing people to associate their identities with a single owner email, but have each journal be contacted only via the contact email.

Personally I think some kind of master account vs child account type situation is worth looking at, but that is much more complex and has its own issues to consider. :-)
thorfinn: <user name="seedy_girl"> and <user name="thorfinn"> (Default)

Re: Anything Can Happen

[personal profile] thorfinn 2012-02-15 02:51 am (UTC)(link)
I thought it was on the list, but wasn't sure. :-)

Possibly helpfully, "Owner email" and "Contact email" probably doesn't require additional explanation, I think people would mostly understand the difference just from the names alone.

Master/child account type stuff is not so obvious to explain to people.
pne: A picture of a plush toy, halfway between a duck and a platypus, with a green body and a yellow bill and feet. (Default)

Re: Anything Can Happen

[personal profile] pne 2012-02-15 11:58 am (UTC)(link)
The left-hand-side of an email address is standards defined as being capable of being anything. Literally, anything. Not even just ascii limited.

And if you want to follow the standard completely, it can even include comments and spaces around internal dots.

As in John . F (for Fitzgerald) . Kennedy@whitehouse.gov.

(At least in RFC 822; I'm not sure whether RFC 2822 or whatever followed that tightened up the allowed syntax.)
thorfinn: <user name="seedy_girl"> and <user name="thorfinn"> (Default)

Re: Anything Can Happen

[personal profile] thorfinn 2012-02-16 01:41 am (UTC)(link)
No change in syntax that I can see. :-) And yes, RFC2822 is the correct one. Although I think I may have exaggerated - the LHS does appear to be limited to 7bit US-ASCII in RFC2822 and RFC2821. But that's still pretty wide. Mind you, there's SMTP protocol options for 8bit mime in transport, and extensions to support UTF8 content in RFC2822 messages (quoted-printable, etc), so...
pne: A picture of a plush toy, halfway between a duck and a platypus, with a green body and a yellow bill and feet. (Default)

Re: Anything Can Happen

[personal profile] pne 2012-02-16 07:24 am (UTC)(link)
And yes, RFC2822 is the correct one.

http://tools.ietf.org/html/rfc5322 : "Obsoletes: 2822"

I just didn't remember the number at the time :)
thorfinn: <user name="seedy_girl"> and <user name="thorfinn"> (Default)

Re: Anything Can Happen

[personal profile] thorfinn 2012-02-24 01:05 am (UTC)(link)
Ooops. Apparently I missed that. :-)