4 ms·
Nice! So you've built "non-realtime email" which gets delivered once a day. Maybe it would make sense to bundle it with its opposite: "realtime texting". Basica
by cousin_it 8y ago
Nice! So you've built "non-realtime email" which gets delivered once a day. Maybe it would make sense to bundle it with its opposite: "realtime texting". Basically it would work like phone calls, but for text. One person initiates with a wordless ping, the other responds, then they can exchange texts, there can be at most one conversation per person at a time, and if you close or unfocus the app for any reason, the conversation stops.
I think these two things together could cover most of my personal communication needs, though it for work communications I'd still need faster-than-daily email.
- dmitryminkovsky 8y agoHi cousin_it. Thank you! Not sure about the realtime text bundling. I like the idea, but I'm afraid it would encroach upon the non-instant space the app provides. > though it for work communications I'd still need faster-than-daily email. This is the most requested feature. Will definitely head in this direction.
- romwell 8y agoHi Dmitry! First, thanks for making the platform. I find it interesting, because it mirrors how I use email with an email client, especially when traveling: retrieve messages - write responses later - send them whenever. To that end, I have two considerations: 1)The defining features of your service (daily collection / sending) are easily client-side. I can already configure my desktop email client to behave like pony.gg with a couple of clicks. So it would make a lot of sense, I think, for you to release an email app. Yes, there are many email apps, but for people who can't resist setting email retrieval interval to <5minutes, less is more. Then the users will be able to keep their @bigcorp.com / @work.org address, while having the full benefit of your service. 2)On the other hand, you can also enforce these features server-side, allowing people to use their favorite IMAP clients. Just allow, say, one 1hr window in a 24hr time span for retrieval, and the same for sending (so people in different timezones can all get their email at 7am, but won't be able to get new messages after getting their email for the first time that day; same with sending). Are there any plans to have 3rd part email client support?
- dmitryminkovsky 8y agoHi Roman, Thank you so much. 1) This is on the way. For a first version, this webapp actually wraps nicely in Cordova, and I intend to publish it in the App/Play stores. Alternatively, you will be able to install it as a PWA. Either way, you will be able to compose offline. I think it would also work well in Electron. 2) This is a bit tricky because Pony is more "email compatible" than it is email. Concretely, (i) Each message can only have one recipient. (ii) There is no subject line (iii) You send things by putting them in the Outbox and letting time pass. I've given it some thought and I think there are ways to smooth all this over and adapt it to IMAP, but I think the result might be clumsy. And there are "philosophical" considerations as well. Pony provides you with a non-instant space to communicate that is separate from the instant everything else. I think combining these two spaces would possibly take something away from the Pony experience? > The defining features of your service (daily collection / sending) By the way, while that is a feature, I don't think it's the defining feature. I think the defining feature is providing a space where people can correspond reflectively instead of reactively. When you've got an email client configured some way, you can always unconfigure it. With Pony, there is no way to make it non-instant. So unless you are rushing to make a pickup, there is reason you'd be rushing to hit send when you compose a message, or worried more messages might come and distract you. There are other apps that batch your email, but there are no apps that give you space and freedom to think like Pony.