3 ms·
"... Posterous has designed a blogging platform where the entire focus is on email. Your email client is the admin interface. For those of us that have an emai
by bootload 18y ago
"... Posterous has designed a blogging platform where the entire focus is on email. Your email client is the admin interface. For those of us that have an email client open all day, posterous seamlessly inserts blogging into the day's natural workflow. ..."
No I disagree with that one.
Maybe my workflow is a bit different but I've found the posting of blogs, images, short messages etc using a purposeful designed interface works better. The bit that doesn't work is joining them together. Flickr, twitter, blogger, wordpress allow you to do one task well. Replacing this process by email is a bottleneck because email clients (in my case 'Evolution') are horrendous things to use as a multi-purpose tool. There is no one way to map what you want to achieve to each service. For example:
- add a blog entry: include title a couple of pages of text with images and some urls (worked)
- twitter entry: quick message to a person with a longish url (text length > 140char, failed and url chopped
- flickr entry: tags + description + title + image (title failed, no tags allowed, no licensing of original images allowed)
I've tried these combinations and had success with the blog, moderate success with the twitter and bit of a failure with the flickr entry. I don't think the idea behind Posterous is bad. It's just the tools I have at my disposal are so clumsy. So the idea of an email interface while it works for me has a lot of rough edges and built-in frustration. Where Posterous does work well is integrating the bits you post, not perfectly but enough to be useful.
- unalone 18y agoThat would be an interesting challenge: seeing if you could create a single interface that did all that WELL. As in, figuring out how to interpret a plaintext input and sort it out into categories.
- bootload 18y ago"... seeing if you could create a single interface that did all that WELL ..." Funny enough I've worked on this for a while and while it's a good idea the effort required is somewhat less than using existing application GUI's to enter data and extract data via feeds or API's. The idea I tried was creating an interface to update multiple services (twitter, flickr, delicious ...) via one page, send to a database and use the api's to auto-update. The hard bits ... - how do you add more services easily? - how will your display code handle lots of empty fields? Lots of conditionals in your templates. Is your templating engine up to it? - how do you selectively and easily send data to one application but not another, some times? Can you change for instance sending links to flickr but not to delicious on a one time basis? - how do you handle sites that have no API's or feeds? Like hackernews which had neither for a long time. The one key advantage of this method is you capture data before you propagate it. So if your well thought out 100 word post (with references) dies because your browser crashes or you press the back button you have a local copy.