Live data from Hacker News

Why Toys?

blog.ycombinator.com

181–190 of 211 posts

Re: Why Toys?

#181

Earlier quoted context omitted.

Given enough time, most applications turn from "feature rich" into "feature bloat."

Feature Rich: Features I use. Feature Bloat: Features I don't use.

I would say: almost. Features I don’t use, that are just kind of there but don’t get in my way aren’t seen as bloat, only the ones that complicate my workflow in some way. For example, I find Jira bloated, because it has loads of options and menus that I must consider when I want to do something, even though I will never use 90% of them, creating an issue has a huge form to fill in, but I only care about maybe 5 or 6 of the fields. These extra features that I don’t use cause cognitive overhead and therefore I consider them bloat. The feature that doesn’t interfere or cause overhead isn’t considered bloat, even if I never use it.

Re: Why Toys?

#182

I am constantly thinking about the question: What is the future tech entrepreneur's lemonade stand? It would have to be something typical and low-skill so a young entrepreneur can build it and learn the hard lessons about running a business, but it needs some special defense to avoid being out-innovated by an Amazon or Google. The Facebook example as a toy is perfect - the platform was able to thrive by being hyper-l…

Look for things that don't scale. At all . A lemonade stand makes sense because it captures people who want lemonade now , but not enough to get in a car and drive to the closest store. In practice, no single shop can scale itself to address this time/location limitation[0]. Similarly, an "e-Lemonade stand" has to be something that just can't scale beyond local level. Anything that a single entity could do for custom…

Isn't this generally building a no-art mobile game? Something like 2048 which doesn't require hiring an artist. Actual amount of money to be made, if any, is too small for larger shops to make it worth their engineering time.

Re: Why Toys?

#183

Earlier quoted context omitted.

Look for things that don't scale. At all . A lemonade stand makes sense because it captures people who want lemonade now , but not enough to get in a car and drive to the closest store. In practice, no single shop can scale itself to address this time/location limitation[0]. Similarly, an "e-Lemonade stand" has to be something that just can't scale beyond local level. Anything that a single entity could do for custom…

Isn't this generally building a no-art mobile game? Something like 2048 which doesn't require hiring an artist. Actual amount of money to be made, if any, is too small for larger shops to make it worth their engineering time.

Yeah, that seems to work too.

Re: Why Toys?

#184

Earlier quoted context omitted.

It still doesn't. But I'll grant it's turning out to be tech's single best attempt at hastening the climate change and cooking us all on this planet.

Bitcoin gives us a way to transfer value which is censorship-resistant. That is BIG.

Which isn't really "an immediate problem" right now for anyone. Also, the "solution" isn't particularly good.

Re: Why Toys?

#185

Earlier quoted context omitted.

What does it say about me that I'd rather build ice skates than ear muffs?

That you're taking the analogy too literally? Ice skating does sound more fun.

On the contrary you are taking ambicapter too literally; I can only assume they meant they'd prefer building ice skates in the metaphorical sense -- they'd rather build for a new desire, than create a solution for a known problem.

Re: Why Toys?

#186
post #159

Earlier quoted context omitted.

I have always considered this the great tragedy of APIs. Their promise is so great yet there are few ways of actually working with them outside of explicit vendor integrations that account for the idiosyncracies between most software. Noting that most SaaS is just differing UI interacting with object models, and it's a bummer that we build this way. It's like we are collectively building a rail network, but every sin…

Agreed in general, but services like IFTTT and Zapier offer a very decent way of integrating otherwise unfriendly APIs, and I think that this will become even more straightforward and common with the rise of conversational interfaces like Alexa

Problem is, most services seem to be designed to interact in the absolute minimum. I use IFTTT myself, but just look at the integrations available! So little of them. 90% of times I have a flow idea, it can't be done with what's available.

(Come to think of it, I have a spare VPS, maybe it's time to try out Huginn.)

RE Alexa, call me a whiner, but "Alexa, ask $BrandApp to XYX" ruins the immersion a lot :(.

Ultimately, the problem is control. On-line services control both your data and how you work with it - from the flow of actions to UI[0]. An interoperable world requires vendors to give up a lot of that control.

--

[0] - They control the entire experience. As if they were a fucking Disneyland, not just a hammer, from users' point of view.

Re: Why Toys?

#187

Earlier quoted context omitted.

UNIX tools can focus on solving a single problem well because they interoperate between themselves, so you can join tools that solve different problems and make something useful out of it. SaaS has no such option. It either does every little thing you need, or it doesn't solve the problem.

IFTT, stitch and segment are some companies that try to solve this problem.

They're ultimately limited to which SaaS lets them, which is usually not much. For many, deep interoperability goes against the core objective of "engagement" (i.e. trapping the user in the service for as long as possible).

Re: Why Toys?

#188
post #157

Earlier quoted context omitted.

If Google Docs provides featureset A,B,C and Office 365 provides features A,B,D; you can never have both C and D at the same time.

Is this specific to SAAS? Suppose Word 2003 has A,B,D and WordPerfect has A,B,C, can you ever have C and D at the same time?

You have a single filesystem, so maybe you can open the same document in both one after another to work on the parts that need D and the parts that need C. Of course this relies on having a common format, but in the local-apps world we mostly have those, whereas in the SaaS world we don't even have a filesystem to share.

Re: Why Toys?

#189

The third thing that goes wrong when you take your toy too seriously is that you immediately start optimizing on the things that you believe serious businesses should – profit and margins. While these things are important in the long run, focusing on them too early injects an impossible set of things for an early startup to do. How is this not in direct contradiction to http://paulgraham.com/aord.html ? Can somebody…

From the PG page you link:

> It's not a question that makes sense to ask early on, any more than it makes sense to ask a 3 year old how he plans to support himself. But as the company grows older, the question switches from meaningless to critical. That kind of switch often takes people by surprise.

There's a point at which you have to worry about profitability, and that point can be earlier than you think, but at the same time it's not something you should be doing right at the start.

Re: Why Toys?

#190
post #92

Earlier quoted context omitted.

Having an abundance of light at night was a novelty and a luxury in the past. Definitely toy territory in my book.

I bought an LCD monitor in 2003. It was a novelty and a luxury to me at the time...but I bought it to solve the problem of not having space for a 20" CRT on my desk at school. I don't see how something being novel and luxurious necessarily means that it's also a toy.

I never claimed it did. Further, I don't think there is a dichotomy here.

You could have solved your problem in a dozen other ways. You were privileged enough to do it in the way that presumable pleased you most. There is a hint of toyness to it in that respect.

Post reply on HN