4 ms·
Thanks for that. Re: "programmable" -- what we're trying to emphasise with that is that it's more programmable than (say) Excel -- the whole Python in cells th
by gpjt 16y ago
Thanks for that.
Re: "programmable" -- what we're trying to emphasise with that is that it's more programmable than (say) Excel -- the whole Python in cells thing, plus its ability to rework the recalculation loop with Python code. Our first cut was actually "a Python cloud spreadsheet" but we figured that we didn't want to tie ourselves down to people who already knew and liked Python, so we moved on to "programmable". Is there a better word, do you think?
We've definitely been thinking about having some kind of option for people to deploy to their own private clouds (or indeed to their own server farms) but I see that we've not put anything on the site about that; we'll add something for that.
I like the idea of having an example of what the different pricing plans/compute time allowances get you, we'll definitely add that.
We've had a lot of debates internally about the concurrent server support; perhaps we should just drop that from the plans entirely?
- vineet 16y agoRe: "programmable". What you are saying makes sense. But when I first see a site that says 'programmable cloud spreadsheet' - I don't get that. Infact, there is a part in me that is still trying to figure out in which problems you are better than Google Spreadsheets and its programming model (even though I understand that you are different from it). Perhaps what you need to do is talk about the problems that you solve instead of what you are building. This will definitely be helpful when trying to get to product/market fit. Re: dropping concurrent server support - I doubt that anyone can really tell you what you should do there. You need to experiment. And the answer right now (with early adopters) might be very different from the answer a few months down the road.
- gpjt 16y agoRight, that makes sense -- the classic benefits versus features balance -- which is, of course, made more complex by the fact that one user's benefit is another user's feature, but that's not to say that there's no balance to strike. One thing we did with our earlier product was to have a "How we can help..." section on the front page, naming three markets, with links through to separate pages for each, naming appropriate problem and solution/benefits for each. Perhaps we need to do the same thing here. Re: what we're better at than Google spreadsheets -- our big benefits come in simplifying complex spreadsheets, by using programmerly techniques such as objects/lists/NumPy arrays in cells, and in automated parallelisation for large calculations. These are definitely power user features, for normal cashflow spreadsheets and the like there's no advantage to using Dirigible instead of Google. (Random thought: we're currently using the example of calculating the orbits of the planets to show a bunch of those features off. We chose that example specifically because it's simple enough for most technical people to grok pretty quickly and doesn't require any real domain knowledge to see what's going on. Perhaps we also need more industry-specific examples to make the same point -- eg. pricing portfolios of exotic options for the finance guys.) Re: concurrent server support -- well, I guess a bit of A/B testing might be in order -- with a mind to the fact that we'll need to keep running the tests as time goes on and we (fingers crossed) cross the chasm.