ACCESS I was saying two things, one you saw a refined version of elsewhere: "making it exciting is more important than making it easy to develop for". Designing a great platform (in terms of the insides being usable for developers) doesn't matter if the platform does something great. Many sins are forgiven if you have this. I think there are probably many examples of horribly ugly technologies that became wildly successful because they enable access to something exciting (DOS? windows? netscape navigator?)
USABILITY To elaborate on the other idea: it's much easier to make something usable if it has a specialized purpose. Fewer features, fewer interactions/interdependencies, fewer controls, fewer things to go wrong - it's gonna be simpler to use. e.g. ipod shuffle. That is, not being able to do things makes it easier to use.
The big problem with a platform is that you don't really know what the specific use will be, nor the exact nature and parameters of it. A platform, by definition, is general, and not specialized to one specific purpose. And you won't even know the nature of the general use. Except, perhaps, that it will want to be part of whatever the cool, exciting thing you have going is - that's a predictive organizing principle.
Therefore, for a platform, rather than trying to guess at the kinds of uses it will have, maybe just say: (1). what is the cool, exciting thing that we enable? (2). how can we let developers build something that has that cool, exciting thing? That is, an API that gives them access to whatever they need to do that. It doesn't need to be great access, they just need to be able to do it somehow.
This is "overgeneral" in the sense that you can not only do the things you want to do, but you can also do things you don't want to do. This looseness makes it harder to use - if it was an exact fit to the problem, it would be a delight to use. This extra power gives you "enough rope to hang yourself".
RAILS On reflection, I think Rails is a much later stage in the development cycle: webapps are in a more mature stage, and by that I mean that people now know what kinds of things they want to do, and most importantly, what kind of defaults are useful. At an earlier stage, we didn't have enough collective experience to know those things. This knowledge is to do with how webapps appear to users externally, as well as what architectures and internal approaches have been found to work. Webapps are becoming an understood art, when previously, it was a bit of a black art.
Rails represents a systemization of webapps; no longer ad hoc, many design decisions are now captured in a mechanical tool. It is specialized to the task.
USABILITY To elaborate on the other idea: it's much easier to make something usable if it has a specialized purpose. Fewer features, fewer interactions/interdependencies, fewer controls, fewer things to go wrong - it's gonna be simpler to use. e.g. ipod shuffle. That is, not being able to do things makes it easier to use.
The big problem with a platform is that you don't really know what the specific use will be, nor the exact nature and parameters of it. A platform, by definition, is general, and not specialized to one specific purpose. And you won't even know the nature of the general use. Except, perhaps, that it will want to be part of whatever the cool, exciting thing you have going is - that's a predictive organizing principle.
Therefore, for a platform, rather than trying to guess at the kinds of uses it will have, maybe just say: (1). what is the cool, exciting thing that we enable? (2). how can we let developers build something that has that cool, exciting thing? That is, an API that gives them access to whatever they need to do that. It doesn't need to be great access, they just need to be able to do it somehow.
This is "overgeneral" in the sense that you can not only do the things you want to do, but you can also do things you don't want to do. This looseness makes it harder to use - if it was an exact fit to the problem, it would be a delight to use. This extra power gives you "enough rope to hang yourself".
RAILS On reflection, I think Rails is a much later stage in the development cycle: webapps are in a more mature stage, and by that I mean that people now know what kinds of things they want to do, and most importantly, what kind of defaults are useful. At an earlier stage, we didn't have enough collective experience to know those things. This knowledge is to do with how webapps appear to users externally, as well as what architectures and internal approaches have been found to work. Webapps are becoming an understood art, when previously, it was a bit of a black art.
Rails represents a systemization of webapps; no longer ad hoc, many design decisions are now captured in a mechanical tool. It is specialized to the task.