It always surprises me when I make a mistake in my code and I don't notice it until I next few the source because the browser has understood what I was meant to do.
I guess although this is good for the end user it isn't always a great thing for developers learning HTML if they're able to write bad HTML without ever knowing they're doing something wrong.
buddy-fund.com - A way for users to sell their Facebook wall to advertisers. We should have done a little more research into the idea, it's against the ToS surprise, surprise.
clanbo.com - (The name is awful, I didn't come up with it) It was a free game server hosting service which also provided premium accounts. It got quite a bit of traffic and made me a little money back when I was 16 but the effort to return ratio is pretty low and in such a competitive area it would be hard to make it into anything worthwhile.
These two domains and sites are available for sell if anyone is interested.
Full source can be provided on both. Clanbo.com fully functional and ready to host both TS2 and TS3 servers.
In regards to what language is best, it probably won't matter too much unless performance is critical to the application. Just pick the language you're most conformable developing in.
Not to sound contrarian, but the 'something' you can do about that is to not ask for their first and last names.
I'm not suggesting that's the right or wrong approach, but you should ask yourself the following questions every time you ask the user to do anything, especially so when asking for their personal information:
- Do I really need this? Does the app break if I don't get it? Does the quality of the app diminish? Is there some measurable way in which this impacts me negatively?
- Can I rely on this? Can it be verified? If a user enters his name as "Pinocchio Dandelion", can I say that it isn't? At this point, if it IS incorrect, refer back to question #1.
By my estimation, generally, if you're asking for names, and it matters, you should probably also be asking for credit card information, or some other way to vet that data. If you aren't expecting to bill them, you probably don't need to ask for it.
Of course, you might have something in the app that does need it that we can't see from the outside, but most commonly in these scenarios is that people think they need the information and really don't, which means that you might have captured an even larger percentage of users in the signup funnel.
In regards to signups, you really really really want to make it as frictionless as possible. Once you have their email address, you almost certainly have a more 'committed' user than someone who hasn't filled out the form at all. If first and last names are nice for you to have (but not strictly necessary), then you can ask for them later, after you have their email address.
Once you have the email address though, that gives you the ability to try and lure them in further. Patio11 (as usual) has more detailed information on this topic, so I'll refer you to his posts as to why having an email address is a really good thing, but suffice it to say, it is.
I totally agree with the question "Do I really need this?"
No I don't. But there is an idea behind asking those information.
I don't care about their data. But I do care about them and I would like to see people who care about the app which will try to solve some problem of them. I would like to have a passionate user base(100s) rather than collecting 1000s of emails. I would like to talk with them, one by one and ask them if we can help them.
Some people told me there are similar tools, some asked me questions, some shared their love and interest to use the app. Some said "Landing page sucks" which I agree a lot! Some asked for a job.. I wouldn't get this if I was only asking their email address.
173 people even wrote something to remarks. Only 60 people did not write their names ( some of them did not write their names but put some remarks )
448 people filled out their name. Only 1 of them has name-surname "In Valid" and his email address is avalid@email.com I bet he is a bot.
First name - Last name fields are not required. People who follow Hacker News are already experienced Web users who knows clearly a sign of Required Field, they might easily skip it, but they did not. The rest of the emails are already indicating their name and surname.
If they don't care and they don't request an invite; which means I would be more efficiently spend my time.
It might have a better conversion rate without asking their name, but I don't care about the conversion rate that much.
Don't get me wrong, I am not against what you say, I am trying to rationalize the behavior with data.
It sounds like you have valid reasons for your rule-breaking, and that's a-okay by me. If we all followed the rules all the time, there wouldn't be any progress.
It also sounds like you're deeply passionate about what you're doing, which is great.
My only caveat to that is that it's hard to have both success at a grand scale and a dedicated group of users at the same time. If you're not looking to be successful, or aren't looking to strike it big (ala Facebook or Twitter), there is of course nothing wrong with that, but for the type of service you're operating, you'll have a harder time tracking statistical trends with a smaller audience I'd suspect, which could make the service overall less effective.
As you might know, without committed users Twitter would not have # tag and @ sign. They have talked with their users at one point. They don't have an option. You have to.
What their advantage right now, Facebook already have 3200+ employees which also means users that they can get feedback.
Twitter has the same nature. But believe me, they are talking a lot with their customers(advertisers), not with you or me, coz we are a small fish in the ocean. Our lives are not dependent on FB or TW, if we find a better app, we will sell them in a second.
That's also why I believe 37signals, Evernote, Dropbox are much more valuable brands than Facebook & Twitter. They might not have 100s million of users, but if you can't monetize, it does not matter
We will be going Freemium, but in a way that Evernote does. Not in FB or TW modal.
I think Square could have tried to be more understanding of this use case.
He did clearly explain that the linked account didn't keep a balance and that he was willing to pay the negative balance in his Square account with other sources.
I don't see this as shockingly poor customer service, but Square should have just disabled the automatic debiting on his account as he was a long time trust worthy customer.
Trustworthy? Jason already demonstrated he is not trustworthy, since he failed to keep the necessary amount of funds in his linked account to cover any chargebacks that may occur. He screwed up, and he expected Square to pay for it.
Square was out the funds immediately. Jason could have avoided fees by funding his account the same day, or by simply keeping some reasonable amount in the account for potential chargebacks.
Square should not be required to keep a person on call to handle special cases like this or to ask merchants nicely for funds for every chargeback to an unfunded Square account. Automated ECH transfer from a linked account is fair and efficient, and once it is initiated can't be stopped.
Although I agree with what you're saying sometimes spending more time on eye candy than the actual design can be useful.
Eye candy doesn't help the user with navigation or add functionality but it can make a website look more professional and in-turn more trustworthy.
For e commerce websites getting the users trust is an important consideration and I'd argue eye candy is maybe just as important as the design.
Of course in the case of Hacker News I wouldn't like to see this kind of redesign implemented and would prefer the focus of the site's design to be solely on improving it's functionality and usability.
For example how would the Google Chrome browser work (and search to a degree), does a user who types "pepsi" into their omnibar want to go to http://pepsi/ or search for pepsi?
It also adds confusion for webmasters trying to parses URLs on their website. When a user types pepsi.com/coke into their blog for example that link can be made clickable to http://pepsi.com/coke/ where it can't for pepsi/coke
The problem of detecting URLs with weird TLDs could be solved by using relative URLs (RFC 1808 §4) with the protocol omitted. It would put that vestigial // to good use—//coca-cola is a URL just as @cocacola is a Twitter handle.
The first promotion was advertised on Twitter and RubyFlow. The second was advertised on Twitter and RubyWeekly. Twitter has always been the best way to spread news about the book.
It always surprises me when I make a mistake in my code and I don't notice it until I next few the source because the browser has understood what I was meant to do.
I guess although this is good for the end user it isn't always a great thing for developers learning HTML if they're able to write bad HTML without ever knowing they're doing something wrong.