Developers: stop re-AOLizing the web!(technicalfault.net)
technicalfault.net
Developers: stop re-AOLizing the web!
http://technicalfault.net/2014/07/03/developers-stop-re-aolizing-the-web/
101 comments
>Technically email isn't the web.
I see this very same things on the web. Heaven forbid you use internet explorer as your browser or are a version behind. The amount of smarmy, "Use a real browser" messages I've gotten when testing things in IE is unacceptable. I have no love for IE, but lots of people use it, and I need to support it at work. Just because its difficult to write html for for certain use cases doesn't mean its useless. I understand when using something IE doesnt support yet, but that didn't seem to be the case with these websites. Often these sites are run by 20-somethings straight out of school with some kind of 'stick it to the man' identity politics. Yeah if you're a middle class person who went to college, have healthcare, have a non back-breaking computer job, etc guess what, you're the man.
I feel like we've never transcended the proprietary mindset and popularity still rules. This email client may be an extreme example, but the web is pretty unfriendly if you're not using firefox or a webkit based browser. Oh, the opposite was true in the past? So what. That doesn't make the current status quo acceptable. I love how we justify the various ways we refuse to learn from history.
On mobile its even worse. We're not even shoving things into silos. We're saying, "Look, this featureset which could be trivially be put into a HTML5 webpage is now a local app proprietary to this platform. Install it, deal with its constant updates, its crappy UI, etc." Does every newspaper in the world and forum really think I want to install their app? I'd have hundreds of apps on my phone if I did.
I really think we're regressing a bit. The cloud-ification and foolproofing of things just leads to a handful of megacorps providing near-mandatory services and applying their own policies and politics onto those services. We keep losing ground to them on things like privacy, stability, ownership, etc for convenience. Not sure where this is going to lead to in the end, but it won't be anything like we're used to. I doubt it'll be for the better. MSN and AOL tried to build a walled web garden in the 90s and were laughed at by the tech-savvy. Now the tech-savvy are the ones sporting ipads and android phones and willingly entering these new walled gardens.
I see this very same things on the web. Heaven forbid you use internet explorer as your browser or are a version behind. The amount of smarmy, "Use a real browser" messages I've gotten when testing things in IE is unacceptable. I have no love for IE, but lots of people use it, and I need to support it at work. Just because its difficult to write html for for certain use cases doesn't mean its useless. I understand when using something IE doesnt support yet, but that didn't seem to be the case with these websites. Often these sites are run by 20-somethings straight out of school with some kind of 'stick it to the man' identity politics. Yeah if you're a middle class person who went to college, have healthcare, have a non back-breaking computer job, etc guess what, you're the man.
I feel like we've never transcended the proprietary mindset and popularity still rules. This email client may be an extreme example, but the web is pretty unfriendly if you're not using firefox or a webkit based browser. Oh, the opposite was true in the past? So what. That doesn't make the current status quo acceptable. I love how we justify the various ways we refuse to learn from history.
On mobile its even worse. We're not even shoving things into silos. We're saying, "Look, this featureset which could be trivially be put into a HTML5 webpage is now a local app proprietary to this platform. Install it, deal with its constant updates, its crappy UI, etc." Does every newspaper in the world and forum really think I want to install their app? I'd have hundreds of apps on my phone if I did.
I really think we're regressing a bit. The cloud-ification and foolproofing of things just leads to a handful of megacorps providing near-mandatory services and applying their own policies and politics onto those services. We keep losing ground to them on things like privacy, stability, ownership, etc for convenience. Not sure where this is going to lead to in the end, but it won't be anything like we're used to. I doubt it'll be for the better. MSN and AOL tried to build a walled web garden in the 90s and were laughed at by the tech-savvy. Now the tech-savvy are the ones sporting ipads and android phones and willingly entering these new walled gardens.
Your rant about IE is strange given that IE, a for a long time, was nonstandard. Think about it, you are asking developers to support a non-standard set of browsers to reach a "large" use base. How is that any different from the guys at mailbox supporting a non-standard API to reach a large user base?
The web looks fine in standard supporting browsers, and as of now that is Gecko and Webkit browsers (which by the way make up 99% of OSS browsers, like Midori and IceCat). Most of the other non-Gecko/Webkit browsers are Trident based, closed source, and only support Windows.
Using the web is a bad example for showing that there is a "proprietary mindset", when in fact all the standards about the web are completely open.
The web looks fine in standard supporting browsers, and as of now that is Gecko and Webkit browsers (which by the way make up 99% of OSS browsers, like Midori and IceCat). Most of the other non-Gecko/Webkit browsers are Trident based, closed source, and only support Windows.
Using the web is a bad example for showing that there is a "proprietary mindset", when in fact all the standards about the web are completely open.
There's an important distinction that needs to be drawn here.
It's perfectly okay to say 'we support modern standards, older versions of IE don't comply with modern standards so if you use IE, you need to upgrade to a recent version'.
It's not okay to say 'you can't use even recent versions of IE because we don't like the brand name'.
(I think it is the former rather than the latter that people are generally doing, but it's worth clarifying the distinction.)
It's perfectly okay to say 'we support modern standards, older versions of IE don't comply with modern standards so if you use IE, you need to upgrade to a recent version'.
It's not okay to say 'you can't use even recent versions of IE because we don't like the brand name'.
(I think it is the former rather than the latter that people are generally doing, but it's worth clarifying the distinction.)
"This email client may be an extreme example, but the web is pretty unfriendly if you're not using firefox or a webkit based browser."
That this would be the case today would have been hard to believe only a few years ago. For quite long, the situation was the opposite.
That this would be the case today would have been hard to believe only a few years ago. For quite long, the situation was the opposite.
It's interesting that you target mobile, while HTML/webapps are actually one of the largest drivers of silo-ization and proprietary lock-in around:
- The code is all stored server-side; you stop paying, or the vendor loses interest, you lose the app. Poof. I can still run applications from the 1990s for research, but I can't run a webapp that disappeared last year.
- The protocols ("REST" not withstanding) are all proprietary. Given any two competing webapps, they almost certainly vend two entirely different protocols.
- Everyone gets the latest version whether they want it or not -- and whether it's a benefit to them, or not. If the company wants to insert ads, or revoke a useful tool that no longer fits their strategy, or take any other action that diminishes the value of user's investment in the app -- they can.
- Lock-in is standard; data is heavily welded to the particular application, and even where data export exists (a rarity), the formats are proprietary and ill-supported elsewhere.
For all the talk of "openness" for developers, the web has created what might be the most open-hostile environment for users we've seen since AOL and Compuserve.
- The code is all stored server-side; you stop paying, or the vendor loses interest, you lose the app. Poof. I can still run applications from the 1990s for research, but I can't run a webapp that disappeared last year.
- The protocols ("REST" not withstanding) are all proprietary. Given any two competing webapps, they almost certainly vend two entirely different protocols.
- Everyone gets the latest version whether they want it or not -- and whether it's a benefit to them, or not. If the company wants to insert ads, or revoke a useful tool that no longer fits their strategy, or take any other action that diminishes the value of user's investment in the app -- they can.
- Lock-in is standard; data is heavily welded to the particular application, and even where data export exists (a rarity), the formats are proprietary and ill-supported elsewhere.
For all the talk of "openness" for developers, the web has created what might be the most open-hostile environment for users we've seen since AOL and Compuserve.
Quite true PaaS and SaaS are all about locking in the users without giving anything back.
No different than the native OS silos that those webdevs argue against all the time.
No different than the native OS silos that those webdevs argue against all the time.
The outdated browser issue doesn't really factor into this.
> over which they have full control
That may just be the problem. When everyone has full control over how they present themselves, then everyone presents themselves differently. The problem with this approach is the inconsistency - a user has to learn their way around a different UX for each entity's presence.
With Facebook and Twitter, it's a familiar UX for the end user, and the information related to different entities is presented in more or less the same format for all entities. This makes is easier for the end user to find the information they are looking for, and sometimes that's better than branding.
So, while it's important for an entity to have a branded web identity, I think that it's equally important for an entity to have and promote a presence on popular social media as well. It's a sort of dumbed-down identity for the masses.
That may just be the problem. When everyone has full control over how they present themselves, then everyone presents themselves differently. The problem with this approach is the inconsistency - a user has to learn their way around a different UX for each entity's presence.
With Facebook and Twitter, it's a familiar UX for the end user, and the information related to different entities is presented in more or less the same format for all entities. This makes is easier for the end user to find the information they are looking for, and sometimes that's better than branding.
So, while it's important for an entity to have a branded web identity, I think that it's equally important for an entity to have and promote a presence on popular social media as well. It's a sort of dumbed-down identity for the masses.
> The reality of "the cloud" is we're squeezing things back into a few giant silos.
Which is fine so long as you can move between silos freely. I think some services are just always going to have t pool resources everyone can't have their own.
Which is fine so long as you can move between silos freely. I think some services are just always going to have t pool resources everyone can't have their own.
Firms advertizing their presence on Facebook and Twitter took a while to catch on. It's an interesting way to stay connected since websites don't do that (and RSS never caught on with non-techies outside of certain applications like podcasts and people are loath to give out their emails for monthly newsletters). Unfortunately, you have to pay for every posting on Facebook for your 'subscribers' to be able to see it.
Not to mention the scads of mostly-useless javascript needed to present every damn site these days. It's Flash all over again.
I can't wait until the js fad dies.
I can't wait until the js fad dies.
Having core functionality dependent on js, if it is trivially avoidable, seems regrettable. But for enhancements, a lot of the experimentation and deviation from strict html in the early days and into the present, has ultimately led to best practices and new useful features being written into the standards. Ideally there should be a balance between interoperability and innovation.
It's a shame, because we could have lots of little, highly interlinked, clouds, not one massive one.
That's the same as with SOA - sounds awesome on the paper but just does not work well in practice. You can have one standard for linking all the things together on paper, but in reality you will get ten slightly incompatible implementations all with their own quirks and enhancements and extensions and suddenly integrating them is all but fun.
If SOA doesn't work for you, you aren't doing enough of it ;-).
You know, "the cloud" worked great as a fully distributed set of systems using standard protocols like SMTP, FTP, DNS, etc. It's not impossible to standardize interfaces. Our industry just needs a reawakening of its anti-silo past.
You know, "the cloud" worked great as a fully distributed set of systems using standard protocols like SMTP, FTP, DNS, etc. It's not impossible to standardize interfaces. Our industry just needs a reawakening of its anti-silo past.
They do this for good reason -- dealing with the various dysfunctional IMAP implementations out there makes your product look lousy and costs alot of time & treasure to support. When some squeaky wheel blogger with a screwed up IMAP server writes a ten page rant about why you suck, nobody gets the other side of the story.
I had a relative who ran a business that only served customers in Manhattan. Brooklyn? Jersey? Not interested.
Why? His competitive edge was understanding his customer base cold. He knew what companies were in what buildings, and all of the trivia about different neighborhoods and streets that let him win bids and save time.
I had a relative who ran a business that only served customers in Manhattan. Brooklyn? Jersey? Not interested.
Why? His competitive edge was understanding his customer base cold. He knew what companies were in what buildings, and all of the trivia about different neighborhoods and streets that let him win bids and save time.
Thank you. As soon as I read "open, well-documented and well-understood platform like email" I laughed, but only because what I really wanted to do was cry. I assume that the author had never had the misfortune of trying to build a MUA or MTA that had to be widely compatible with other implementations.
If you have the option of talking only to Gmail and still being successful? Yes.
If you have the option of talking only to Gmail and still being successful? Yes.
I think it's high time to revise the IMAP/SMTP interface for clients anyway; the JMAP spec that fastmail has put together is pretty interesting: http://jmap.io/
A really good way to encourage innovation in the mail client space might be to write a proxy server for JMAP (or something similar) to a legacy IMAP/SMTP setup, and hide all the legacy IMAP/SMTP issues inside the proxy so that building a client anyone can use could actually be fun.
A really good way to encourage innovation in the mail client space might be to write a proxy server for JMAP (or something similar) to a legacy IMAP/SMTP setup, and hide all the legacy IMAP/SMTP issues inside the proxy so that building a client anyone can use could actually be fun.
I'm planning to chat to people at OSCON later this month about JMAP, and we're making a big push at FastMail to do exactly what you suggest - build a proxy that can wrap any IMAP/SMTP setup.
It won't be quite so fast as running a server that can support JMAP natively (we also plan to build an open-source JMAP server on top of the Cyrus IMAPd that we use internally) - but it will bridge the gap :)
It won't be quite so fast as running a server that can support JMAP natively (we also plan to build an open-source JMAP server on top of the Cyrus IMAPd that we use internally) - but it will bridge the gap :)
I don't know why the developer of Mailbox decided to only support Gmail and Apple iCloud. But I do know that making an IMAP client is extremely painful. I once had to, and I can't remember having to deal with a more confusing or frustrating interface.
I do not have the numbers but significant amount of iOS users have Gmail or iCloud mail accounts. Mailbox was originally only for iOS and Gmail, later they have added iCloud, later they have added Android. Maybe in some time IMAP will be added as well. But it is sure as hell more viable to start with something that covers enough users to keep the lights going before trying to do everything.
I concur. I had to test a new IMAP Server for a Linux distro years ago, a lot of complexity.
POP is pretty darn simple though. I used to read mail, when away from home, using 'telnet mail.example.com 110'.
A few points that seem to make the author's argument stronger:
AOL is, unfortunately, far from dead. There are still plenty of AOL email addresses out there. This is a problem. I've run my own email server for a decade or so, with very few problems. AOL is one of the problems. Every now and then AOL bounces one of my emails with an error code that signifies that my IP has been associated with spam or something of the sort. I know this is bogus. No spam, newsletters, or any form of email marketing comes from that IP. In the past I used to go through the steps to get my IP off their list, and they would always do so immediately. I don't bother anymore. If you use AOL you may not get all your email. If you don't like that, get a real email address. (The bans tend to last only a day or so.)
Google claims to be operating SMTP and IMAP servers, and they almost are. But they make slight adjustments to the protocols that tend to enhance their control.[0] They mostly follow the RFPs that specify how an SMTP server is supposed to behave, but violate them when they feel like it, while still advertising themselves as an SMTP server. You just need to experiment to discover what their servers will actually do with your email.
[0] http://lee-phillips.org/gmailRewriting/
AOL is, unfortunately, far from dead. There are still plenty of AOL email addresses out there. This is a problem. I've run my own email server for a decade or so, with very few problems. AOL is one of the problems. Every now and then AOL bounces one of my emails with an error code that signifies that my IP has been associated with spam or something of the sort. I know this is bogus. No spam, newsletters, or any form of email marketing comes from that IP. In the past I used to go through the steps to get my IP off their list, and they would always do so immediately. I don't bother anymore. If you use AOL you may not get all your email. If you don't like that, get a real email address. (The bans tend to last only a day or so.)
Google claims to be operating SMTP and IMAP servers, and they almost are. But they make slight adjustments to the protocols that tend to enhance their control.[0] They mostly follow the RFPs that specify how an SMTP server is supposed to behave, but violate them when they feel like it, while still advertising themselves as an SMTP server. You just need to experiment to discover what their servers will actually do with your email.
[0] http://lee-phillips.org/gmailRewriting/
What sort of IP do you have? If it is some residential IP where the PTR does not match the mailserver’s advertised hostname or the PTR does not resolve to the IP, I can fully understand blocking that IP (and do so myself).
On the other hand, I don’t quite see how a fixed IP could get detected as spammy by AOL without there being any spam sent from it.
On the other hand, I don’t quite see how a fixed IP could get detected as spammy by AOL without there being any spam sent from it.
AOL employs the sort of bad administration that blocks entire IP ranges. They've tried to make their blacklist tools smarter than they are capable of supporting. This is just one of many ways AOL's email service has been subpar, stretching back to day one.
Ah, that’s indeed a silly thing to do; thanks for the warning! :)
Building a tool to enhance the experience of another service isn't the same as building or supporting a walled garden.
That's like saying "developing for iOS||Android||Windows Phone||Symbian is supporting a walled garden!" or "making a petrol||diesel||electric car is supporting a walled garden!"
No - it's like making something that improves something else, for a demographic that you've decided has some kind of benefit to you or your interests longer term.
That's like saying "developing for iOS||Android||Windows Phone||Symbian is supporting a walled garden!" or "making a petrol||diesel||electric car is supporting a walled garden!"
No - it's like making something that improves something else, for a demographic that you've decided has some kind of benefit to you or your interests longer term.
> Building a tool to enhance the experience of another service isn't the same as building or supporting a walled garden.
Building a tool that enhances a walled garden is supporting a walled garden.
> That's like saying "developing for iOS||Android||Windows Phone||Symbian is supporting a walled garden!" or "making a petrol||diesel||electric car is supporting a walled garden!"
Where an operating system only allows you to run programs that the makers of that OS approve, then it is a walled garden, and writing software for it certainly is supporting a walled garden.
> "making a petrol||diesel||electric car is supporting a walled garden!"
Bad analogy, since none of these things are monopolies of one company.
Building a tool that enhances a walled garden is supporting a walled garden.
> That's like saying "developing for iOS||Android||Windows Phone||Symbian is supporting a walled garden!" or "making a petrol||diesel||electric car is supporting a walled garden!"
Where an operating system only allows you to run programs that the makers of that OS approve, then it is a walled garden, and writing software for it certainly is supporting a walled garden.
> "making a petrol||diesel||electric car is supporting a walled garden!"
Bad analogy, since none of these things are monopolies of one company.
[deleted]
> That's like saying "developing for iOS||Android||Windows Phone||Symbian is supporting a walled garden!"
How is it not though? One of the defining features of each mobile platform is its rich third party app ecosystem.
iOS was the mobile platform for a good period of time because the apps only it had. Therefore, those third party developers did in fact support the walled garden, you could even go as far to say that without these developers, the walled garden never would have been what it is today.
How is it not though? One of the defining features of each mobile platform is its rich third party app ecosystem.
iOS was the mobile platform for a good period of time because the apps only it had. Therefore, those third party developers did in fact support the walled garden, you could even go as far to say that without these developers, the walled garden never would have been what it is today.
In fact, that goes as far as Apple basing some of their TV campains entirely on apps they haven't developped. Even now.
Very valid replies, I guess I'm being clumsy with the language a bit.
It seems odd to criticise Mailbox for only supporting limited services because where is the line to be drawn? If it extends to include Yahoo, Live, Outlook, does that cause it to lose its Walled Garden Supporter's badge? What about mail.com, hushmail, topmail, safe-mail, etc, etc, etc.
There is no possible way every feature could be delivered on every platform at launch (I already said this in another comment here), so I guess my point was that it seems unreasonable to bash Mailbox as a Walled Garden Supporter just because it started in one place. Everyone has to start somewhere - otherwise if the launch criteria is perfect, ubiquitous software there would be quite literally no software available.
It seems odd to criticise Mailbox for only supporting limited services because where is the line to be drawn? If it extends to include Yahoo, Live, Outlook, does that cause it to lose its Walled Garden Supporter's badge? What about mail.com, hushmail, topmail, safe-mail, etc, etc, etc.
There is no possible way every feature could be delivered on every platform at launch (I already said this in another comment here), so I guess my point was that it seems unreasonable to bash Mailbox as a Walled Garden Supporter just because it started in one place. Everyone has to start somewhere - otherwise if the launch criteria is perfect, ubiquitous software there would be quite literally no software available.
You're missing the point. You don't need to build in support for Yahoo, Live, Outlook etc separately. We've got standards (like IMAP) which have been designed specifically to enable interoperability of software from different vendors.
The tool supports a walled garden at any point it requires its' user to use such a platform to interface with it.
As the developer of a similar iPhone app which was GMail only (EmptyInbox), let me just say: IMAP is really, really hard to get right. Each different mail provider is different and nobody is keeping all the rules. Even Google had a few hacky differences to the "official" IMAP way of doing things.
I can completely understand why Mailbox only supports GMail and iCloud...so actually, we need to be getting on Google and Apple's case rather than app developers. Not that I'm biased or anything...
I can completely understand why Mailbox only supports GMail and iCloud...so actually, we need to be getting on Google and Apple's case rather than app developers. Not that I'm biased or anything...
[deleted]
So, let me get this straight. You're upset, because a proprietary software application that supports proprietary protocols from proprietary service providers, is not using open standards? If only there was a solution...
Proprietary software and proprietary standards are not the same thing.
They tend to go hand-in-hand, though.
What would you possibly be insinuating atoponce? Thoughts of opennes and freedom? Some GNUs running around in my head, are you suggesting freedom in our IT world?
> Google (and to a lesser extent) Apple, Facebook and Twitter, have little interest in allowing their products to inter-operate in a meaningful way.
Having had to deal with Google's somewhat non-compliant implementation of IMAP recently, I'm not going to say that they're big on having their products interoperate.
However, I would be hard-pressed to make a case that Google is less interested than Apple, Facebook, and Twitter in having their products inter-operate, either with their own or with other companies'.
Google's entire business model requires a far more open web than the other three properties, in order to function. They still don't favor a truly open web, but they're far less siloed than Apple, Facebook, and Twitter, whose business models all require[0] siloes in order to function (though for completely different reasons, hence why Apple and Facebook aren't competitive the way Google/Apple or Google/Facebook are).
[0] Twitter is arguably the only exception here.
Having had to deal with Google's somewhat non-compliant implementation of IMAP recently, I'm not going to say that they're big on having their products interoperate.
However, I would be hard-pressed to make a case that Google is less interested than Apple, Facebook, and Twitter in having their products inter-operate, either with their own or with other companies'.
Google's entire business model requires a far more open web than the other three properties, in order to function. They still don't favor a truly open web, but they're far less siloed than Apple, Facebook, and Twitter, whose business models all require[0] siloes in order to function (though for completely different reasons, hence why Apple and Facebook aren't competitive the way Google/Apple or Google/Facebook are).
[0] Twitter is arguably the only exception here.
Minimal Viable Feature Set.
Support those well, decide later if it makes business sense to support others.
The elephant in the room here is that openness doesn't make business sense given the current state of the industry.
Yes! Unless, whilst we're here, we just stop releasing anything at all until it's absolutely perfect and implements all possible features in all possible scenarios across all possible platforms from day 1.
Anything less is building a walled garden!
Anything less is building a walled garden!
AOL was successful for a reason: It made this complex stuff simple. There is absolutely nothing wrong with that. If you want users to be free from silos then you're going to have to find a way to make it easier for them rather than to tell them they should abandon these services and accept the complexity. Integrated services can offer a level of simplicity to their users that is very hard to achieve in a decentralized manner.
When I introduced ny grandmother to the Internet, I gave her AOL because it was supposed to be "easy." She hated it, and switched to a regular ISP with Netscape for mail and browsing. This was a woman who struggled to even use a mouse, though she was very smart.
Never underestimate how much worse an "easy" silo can actually be. The marketing doesn't always match reality. The garden walls may yet be removed.
Never underestimate how much worse an "easy" silo can actually be. The marketing doesn't always match reality. The garden walls may yet be removed.
It's perfectly logical for this cycle to be occurring.
It's nothing more than technology inflection points in action. It will continue to repeat and there is nothing that can stop that.
Seeking to stop the so-called AOL'izing is like asking nature to stop making wild fires. These things happen for a reason, it's not a fluke, it's not bad. It will cycle. Prepare for the next cycle shift, don't lament today, build tomorrow, it's that simple.
It's no different than being upset about Android becoming the latest operating system monopoly, replicating what Windows accomplished 20 years prior. Stop operating system monopolies! Well, it's perfectly natural and will continue to happen. If someone has been around tech for more than a few years and hasn't figured out how these cycles and networks function, they must really not be paying attention.
It's nothing more than technology inflection points in action. It will continue to repeat and there is nothing that can stop that.
Seeking to stop the so-called AOL'izing is like asking nature to stop making wild fires. These things happen for a reason, it's not a fluke, it's not bad. It will cycle. Prepare for the next cycle shift, don't lament today, build tomorrow, it's that simple.
It's no different than being upset about Android becoming the latest operating system monopoly, replicating what Windows accomplished 20 years prior. Stop operating system monopolies! Well, it's perfectly natural and will continue to happen. If someone has been around tech for more than a few years and hasn't figured out how these cycles and networks function, they must really not be paying attention.
Perhaps the author fails to see that introducing more functionality is additional support. A developer or team has to now support and bugfix more then just Gmail and iCloud which already hits 80% of the market share for this use case. Just my $0.02.
I'm not 100% sure but I thought Mailbox needed access to certain things that are outside IMAP to do what it does. For instance, it makes its own folder in Gmail that it interacts with, and I'm not 100% sure if "Archive" is a standard IMAP function.
I'm not an IMAP dev so I'm open to hearing differently from someone who knows better, but it was my understanding a network-neutral IMAP solution wasn't tenable.
I'm not an IMAP dev so I'm open to hearing differently from someone who knows better, but it was my understanding a network-neutral IMAP solution wasn't tenable.
K-9 mail on Android uses IMAP and it creates new folders, as well as archive my email to my "Archive" folder without a problem. There should be absolutely no reason a mail application couldn't use IMAP to communicate with mail servers.
Doesn't directly address the original author's concern, but he ought to try Boxer--similar application, does support IMAP.
I'm not sure what the author's gripe is. First, if you don't like walled gardens then simply don't use them. Second, if you're adamant they shouldn't exist, then why not roll your open source alternative? Good luck with trying to get "dumb" users to adopt your solution.
I don't see Mailbox AOL-izing the web. I do see ISP attempting to do this.
If they can lock down the content that you see based on what they're getting paid to show to you, that's effectively what AOL was doing in the 90's and early 00's.
They're creating that walled garden around content.
If they can lock down the content that you see based on what they're getting paid to show to you, that's effectively what AOL was doing in the 90's and early 00's.
They're creating that walled garden around content.
Point about IMAP is right on. All else is utter nonsense. Author mistakenly assumes that user experience plus features carries on to IMAP which is..wrong.
Users are a pyramid. At the top of the pyramid are highly technical users who spend all day not minding spending all day dealing with hostile and spiteful interfaces to get trivial tasks done - there are very few of these people in the world. As you progressively work your way down the pyramid users become progressively less inclined to tolerate this nonsense and the number of people in that segment grows.
At the very bottom, the largest population of possible users, are people who's toleration of any sort of confusion of nonsense from their computer device things is at zero.
As a company, you have to decide how far down this pyramid you want to target your products. The lower down the pyramid, the more work you have to put into your product on the usability side, you may even decide to ignore higher tiers on the pyramid because you can only put so much effort into a product, and the upper bits of the pyramid represent an astonishingly small fraction of the market space.
AOL did one thing really well, they decided early on to target the absolute bottom tier of the pyramid that they could recognize. This is pre-Internet days where practically everything you ever wanted to do with a computer was user-hostile. They didn't give two shits about users who knew all of the Hayes command set by heart, because those users were 1% of the entire possible market and supporting them was as much effort as supporting the 99% they were trying to get money out of.
The Internet didn't even immediately kill AOL, as in their own controlled user interface. It really was easier to start "your AOL" wait a minute for the funny sounds to stop and type in "gardening" to get more than enough information about that subject. You could even guess at keywords, "cars" or "cooking" probably took you someplace as well.
The Internet started at the absolute top-most part of the pyramid and we've spent decades trying to get it to work where all the money is, the bottom bits. It hasn't helped that there were all sorts of unexplainable (to the common user) hanger ons and hatefulness that users have had to deal with along the way. But every time we improve the experience a little, high fives everywhere and the bottom lines jumps another million dollars.
Anybody remember the old ways to setup an email client? Remember all the little bits and pieces of information you needed, POP3 or IMAP mail server, SMTP server, authentication, encryption methods, different user/pass for sending and receiving, opening firewalls, setting spam filters, etc?
Then it got better. The last time I set up Thunderbird I supplied it with approximately two pieces of information, my email address and my password.
Do you remember how an AOL user set up their mail? They didn't.
Why is this important? Because that other stuff is hateful to the user. It's also pointless. It never should have gotten to the point where I needed all that stuff just to get my email. But that's what happens when you design software for the top of the pyramid. You can make it as obtuse, undocumented/poorly documented and hostile as you want, and there will still be a small population at the top of that pyramid who won't mind dealing with it.
I was pondering the other day the vast reduction in websites (and other internet services) that I typically visit and use in a day from 10-20 years ago. Pretty much I use, HN, Reddit, Facebook, gmail and youtube for fun and my corporate equivalents for work. I felt sad for a moment because the internet used to seem so much more chaotic and vibrant.
I'm pretty sure that 10-20 years ago I'd have spent time on USENET, telnetted into something, fought with my mail client, hit as many ftp servers as web sites, probably at least 1 gopher site and more. I'd have probably searched for any search term on multiple search engines to make sure I wasn't missing any results and more. 20 years ago I would have even supplemented my time on the Internet with time on local BBS's, each with different interfaces and services.
But today what's the point? I didn't like calling into all those BBSs, or going to all those sites. One site with all those services is much less user-friction to deal with. I didn't like mucking around in some command-line ftp client, why shouldn't I just have a link on a webpage someplace to download something? Why should I telnet into some message board to talk about the Amiga when some meta-message board service lets me just go to /r/amiga? What's the point of gopher when the web works so much better? Why USENET when I can find better, less spammy conversation on HN or reddit?
And guess what? It's even better than that! I can shop on-line, I don't have to drive anywhere, deal with parking, deal with people, deal with the heat. From my toilet, on my phone, I can buy just about anything I'd ever want to buy and have it delivered to my front door within 48 hours.
It's not just that the world today is more convenient, in some notional tradeoff of power vs. convenience, it really is actually better. We're not quite at AOL levels of simplicity. I still have to waste time explaining to my mom why she needs to type "https://www." when all she wants to do is type the name of her bank and have it go there.
More importantly, there's absolutely nothing preventing anybody from doing any of the old things. Want to run a gopher site? Set up a gopher server and do it! Want to run your own private message board behind an obscure domain name? do it! You can still target that top of the pyramid user if you want to, but understand that if you want to make money from it...well...good luck.
At the very bottom, the largest population of possible users, are people who's toleration of any sort of confusion of nonsense from their computer device things is at zero.
As a company, you have to decide how far down this pyramid you want to target your products. The lower down the pyramid, the more work you have to put into your product on the usability side, you may even decide to ignore higher tiers on the pyramid because you can only put so much effort into a product, and the upper bits of the pyramid represent an astonishingly small fraction of the market space.
AOL did one thing really well, they decided early on to target the absolute bottom tier of the pyramid that they could recognize. This is pre-Internet days where practically everything you ever wanted to do with a computer was user-hostile. They didn't give two shits about users who knew all of the Hayes command set by heart, because those users were 1% of the entire possible market and supporting them was as much effort as supporting the 99% they were trying to get money out of.
The Internet didn't even immediately kill AOL, as in their own controlled user interface. It really was easier to start "your AOL" wait a minute for the funny sounds to stop and type in "gardening" to get more than enough information about that subject. You could even guess at keywords, "cars" or "cooking" probably took you someplace as well.
The Internet started at the absolute top-most part of the pyramid and we've spent decades trying to get it to work where all the money is, the bottom bits. It hasn't helped that there were all sorts of unexplainable (to the common user) hanger ons and hatefulness that users have had to deal with along the way. But every time we improve the experience a little, high fives everywhere and the bottom lines jumps another million dollars.
Anybody remember the old ways to setup an email client? Remember all the little bits and pieces of information you needed, POP3 or IMAP mail server, SMTP server, authentication, encryption methods, different user/pass for sending and receiving, opening firewalls, setting spam filters, etc?
Then it got better. The last time I set up Thunderbird I supplied it with approximately two pieces of information, my email address and my password.
Do you remember how an AOL user set up their mail? They didn't.
Why is this important? Because that other stuff is hateful to the user. It's also pointless. It never should have gotten to the point where I needed all that stuff just to get my email. But that's what happens when you design software for the top of the pyramid. You can make it as obtuse, undocumented/poorly documented and hostile as you want, and there will still be a small population at the top of that pyramid who won't mind dealing with it.
I was pondering the other day the vast reduction in websites (and other internet services) that I typically visit and use in a day from 10-20 years ago. Pretty much I use, HN, Reddit, Facebook, gmail and youtube for fun and my corporate equivalents for work. I felt sad for a moment because the internet used to seem so much more chaotic and vibrant.
I'm pretty sure that 10-20 years ago I'd have spent time on USENET, telnetted into something, fought with my mail client, hit as many ftp servers as web sites, probably at least 1 gopher site and more. I'd have probably searched for any search term on multiple search engines to make sure I wasn't missing any results and more. 20 years ago I would have even supplemented my time on the Internet with time on local BBS's, each with different interfaces and services.
But today what's the point? I didn't like calling into all those BBSs, or going to all those sites. One site with all those services is much less user-friction to deal with. I didn't like mucking around in some command-line ftp client, why shouldn't I just have a link on a webpage someplace to download something? Why should I telnet into some message board to talk about the Amiga when some meta-message board service lets me just go to /r/amiga? What's the point of gopher when the web works so much better? Why USENET when I can find better, less spammy conversation on HN or reddit?
And guess what? It's even better than that! I can shop on-line, I don't have to drive anywhere, deal with parking, deal with people, deal with the heat. From my toilet, on my phone, I can buy just about anything I'd ever want to buy and have it delivered to my front door within 48 hours.
It's not just that the world today is more convenient, in some notional tradeoff of power vs. convenience, it really is actually better. We're not quite at AOL levels of simplicity. I still have to waste time explaining to my mom why she needs to type "https://www." when all she wants to do is type the name of her bank and have it go there.
More importantly, there's absolutely nothing preventing anybody from doing any of the old things. Want to run a gopher site? Set up a gopher server and do it! Want to run your own private message board behind an obscure domain name? do it! You can still target that top of the pyramid user if you want to, but understand that if you want to make money from it...well...good luck.
I don't think this comment deserved downvotes, because it makes an important point. If we want to preserve open standards - and I definitely do - then using them has to be straightforward. Think about it: how many of us grow our own food, generator own electricity, dig our own wells? Damn few. We subscribe to the big central services for the things we consume, because life is short. We cannot expect other professions to grant us special consideration that we don't grant to others.
Right. If the standard that we apply to computing were applied everywhere else, we'd all be sitting at home spinning fabric from the wool we just sheered from our goats that we raised with the crops we just harvested.
Nobody does that because it's not a good way to do things.
One of the problems that tech people have is they get mired down in the details, seeing each step as some kind of accomplishment, when each step is just a necessary part of the whole. Raising a crop from seed to harvest isn't easy, but the goal is to have clothes -- yet tech people will spend an impossibly enormous amount of time on tweaking the harvesting process when it's all just going to end up as wool underpants in the end.
And of course, downvotes because I'm supplying uncomfortable facts about population distributions that every marketer on the planet knows.
Nobody does that because it's not a good way to do things.
One of the problems that tech people have is they get mired down in the details, seeing each step as some kind of accomplishment, when each step is just a necessary part of the whole. Raising a crop from seed to harvest isn't easy, but the goal is to have clothes -- yet tech people will spend an impossibly enormous amount of time on tweaking the harvesting process when it's all just going to end up as wool underpants in the end.
And of course, downvotes because I'm supplying uncomfortable facts about population distributions that every marketer on the planet knows.
IMAP was created in 1986.
You'll have to excuse app authors for not turning a blind eye towards the modern APIs that vendors expose.
To have a great standard, you need to have a non-standard predecessor that sets the tone, approach and philosophy and has proven itself out in the wild without the crutch of a standards body mandating its use. In this way "closed" and "open" work hand in hand to form a healthy ecosystem.
Good standards can't materialize in vacuum. "Non-standard" APIs are the fertile soil they grow in. Most of HTML5 was proprietary extensions before they were standardized. In fact, most of HTML has been "vendor specific" before it was standardized (including the <img> tag).
What is the alternative anyway? To "stop re-AOLizing the web" means to stop progress and stick with a horrible email protocol that has seen little improvement since it was created 30 years ago.
EDIT: All right, people are angry because I'm not acknowledging the current version, IMAP4, which was coined in 1993. Sorry, sorry. That makes it a very modern standard. It completely changes everything I said.
You'll have to excuse app authors for not turning a blind eye towards the modern APIs that vendors expose.
To have a great standard, you need to have a non-standard predecessor that sets the tone, approach and philosophy and has proven itself out in the wild without the crutch of a standards body mandating its use. In this way "closed" and "open" work hand in hand to form a healthy ecosystem.
Good standards can't materialize in vacuum. "Non-standard" APIs are the fertile soil they grow in. Most of HTML5 was proprietary extensions before they were standardized. In fact, most of HTML has been "vendor specific" before it was standardized (including the <img> tag).
What is the alternative anyway? To "stop re-AOLizing the web" means to stop progress and stick with a horrible email protocol that has seen little improvement since it was created 30 years ago.
EDIT: All right, people are angry because I'm not acknowledging the current version, IMAP4, which was coined in 1993. Sorry, sorry. That makes it a very modern standard. It completely changes everything I said.
Progress for the sake of progress is not progress.
The question that should be asked is if not using IMAP gives for this app any edge over not using it? It seems that the answer is no.
The question that should be asked is if not using IMAP gives for this app any edge over not using it? It seems that the answer is no.
>The question that should be asked is if not using IMAP gives for this app any edge over not using it? It seems that the answer is no.
This isn't true and it seems you have never used the app, so you don't know if an IMAP implementation doesn't actually have an edge over it.
IIRC, Mailbox actually had the ability to read your emails - some of the features they provided meant their servers had to have access to your inbox. Now, for this to work on IMAP, that meant giving Mailbox your email and password, and for Mailbox to store that in more-or-less plaintext.
Now as an enduser using Gmail, would you prefer that Mailbox stored your password somewhere in us-east-1, or an easily revokable oauth token?
This isn't true and it seems you have never used the app, so you don't know if an IMAP implementation doesn't actually have an edge over it.
IIRC, Mailbox actually had the ability to read your emails - some of the features they provided meant their servers had to have access to your inbox. Now, for this to work on IMAP, that meant giving Mailbox your email and password, and for Mailbox to store that in more-or-less plaintext.
Now as an enduser using Gmail, would you prefer that Mailbox stored your password somewhere in us-east-1, or an easily revokable oauth token?
This doesn't make sense.
Mailbox only works with Gmail and iCloud Mail. Gmail supports OAuth2.0 [0] while iCloud does not [1,2]. On the other hand, Outlook supports OAuth2.0 [3] and is not supported by Mailbox.
Thus, even if the choice of the authors of Mailbox gave them some edge, it is surely not the one you described.
[0] https://developers.google.com/gmail/xoauth2_protocol [1] http://stackoverflow.com/questions/18649352/is-there-an-iclo... [2] http://www.iphonehacks.com/2014/01/apps-ask-icloud-password-... [3] http://msdn.microsoft.com/en-us/library/dn440163
Mailbox only works with Gmail and iCloud Mail. Gmail supports OAuth2.0 [0] while iCloud does not [1,2]. On the other hand, Outlook supports OAuth2.0 [3] and is not supported by Mailbox.
Thus, even if the choice of the authors of Mailbox gave them some edge, it is surely not the one you described.
[0] https://developers.google.com/gmail/xoauth2_protocol [1] http://stackoverflow.com/questions/18649352/is-there-an-iclo... [2] http://www.iphonehacks.com/2014/01/apps-ask-icloud-password-... [3] http://msdn.microsoft.com/en-us/library/dn440163
That, sadly, is why I am not longer an Apple user.
1990-2000, I was an enormous Apple fanatic. I went to user group meetings. I read everything I could get my hands on about their tech.
When I learned to program C/C++ on windows machines at school, I'd come home and re-implement what I had learned using Codewarrior on my Mac.
Then, Jobs's return marked an era of change for change's sake. Apple went from being "different because different is better" to being "different because different is different".
I'm all about progress and improvement but I despise unnecessary and unproductive change.
1990-2000, I was an enormous Apple fanatic. I went to user group meetings. I read everything I could get my hands on about their tech.
When I learned to program C/C++ on windows machines at school, I'd come home and re-implement what I had learned using Codewarrior on my Mac.
Then, Jobs's return marked an era of change for change's sake. Apple went from being "different because different is better" to being "different because different is different".
I'm all about progress and improvement but I despise unnecessary and unproductive change.
What you say makes sense.
It would be nice if Google were publishing their protocol as a standard that could be adopted by others, and eventually adopted as a formal standard.
But they don't seem to show much interest in doing so. There are certainly plausible reasons for this that are not simply related to maintaining their market dominance -- it is cheaper and easier to be able to change your protocol whenever and as often as you need to for your business, rather than try to align to interoperability.
So. What options do 'we' have for trying to move things along the process you describe, where proprietary innovation leads to inter-operable standard, when some key 500 pound gorilla players show little interest in doing so (or in some cases arguably an interest in resisting this)?
There are some similarities between the situation with email and that of html and browsers, although some significant differences, but perhaps the relative recent success (relative!) in maintaining interoperable and documented standards in browsers would be useful to compare and contrast. Email does not seem to be heading in that direction at the moment.
It would be nice if Google were publishing their protocol as a standard that could be adopted by others, and eventually adopted as a formal standard.
But they don't seem to show much interest in doing so. There are certainly plausible reasons for this that are not simply related to maintaining their market dominance -- it is cheaper and easier to be able to change your protocol whenever and as often as you need to for your business, rather than try to align to interoperability.
So. What options do 'we' have for trying to move things along the process you describe, where proprietary innovation leads to inter-operable standard, when some key 500 pound gorilla players show little interest in doing so (or in some cases arguably an interest in resisting this)?
There are some similarities between the situation with email and that of html and browsers, although some significant differences, but perhaps the relative recent success (relative!) in maintaining interoperable and documented standards in browsers would be useful to compare and contrast. Email does not seem to be heading in that direction at the moment.
The earth was created over 4.5 billion years ago. I think 1986 is looking pretty young.
One of my least favorite arguments on HN goes like this: foo is old. Full stop. Entirety of argument. As if by virtue of being "old" (definition varies) it should be obvious to everyone that it's not as suitable as whatever thing popped up overnight.
One of my least favorite arguments on HN goes like this: foo is old. Full stop. Entirety of argument. As if by virtue of being "old" (definition varies) it should be obvious to everyone that it's not as suitable as whatever thing popped up overnight.
How about this: There are use cases in 2014 that are not covered by a standard built in 1986. As such, to accommodate these things, people have made incompatible extensions to the format, making interoperability very difficult. As such, we need to standardize the way we do these expanded things, whether we put some formal extensions to IMAP or we replace it.
That's quite insightful to compare a 1986 network protocol to a 1986 planet, thank you for enlightening me.
Now I feel justified comparing a 1986 network protocol to a 1986 pizza. Would you take a bite?
Now I feel justified comparing a 1986 network protocol to a 1986 pizza. Would you take a bite?
My point was that old is not a cheap way to boost your argument. TCP is also old. So? A list of reasons why it doesn't work would be more convincing. IMAP works.
Understood. Saying "old" is an invalid argument, even among people who are supposed to understand the context. But comparing IMAP to Earth is very valid. It's a marvel of rational thought. You must be very popular.
Everyone who uses IMAP knows its weaknesses. I'm not going to write a book here. It's very, very slow; it has bizarre choices - I still don't understand why I need to delete my message, and then delete the deleted message; it doesn't support now commonplace modern features like tags; its push extension is so naive and resource taxing, companies just implement their own, even when otherwise trying to use IMAP.
But just being slow is an argument enough. I use a few email clients, only one client uses IMAP, and my stomach curls into a ball every time I open it, because I know it'll be synching forever. Even if IMAP being old is a poor argument, me getting old while waiting for it synching, sure is.
Everyone who uses IMAP knows its weaknesses. I'm not going to write a book here. It's very, very slow; it has bizarre choices - I still don't understand why I need to delete my message, and then delete the deleted message; it doesn't support now commonplace modern features like tags; its push extension is so naive and resource taxing, companies just implement their own, even when otherwise trying to use IMAP.
But just being slow is an argument enough. I use a few email clients, only one client uses IMAP, and my stomach curls into a ball every time I open it, because I know it'll be synching forever. Even if IMAP being old is a poor argument, me getting old while waiting for it synching, sure is.
[deleted]
It is slightly stupid to pretend that IMAP was created in 1986 and then never changed.
critics: stop telling me what to build. make it yourself if you feel so strongly
Don't put a bad restaurant review on yelp if you don't know how to cook. I understand that the difference here is that the reviewer is also a dev, but it does not change much since he put this up as a user.
It's the difference of saying that a restaurant makes bad food when you're a bad cook, versus saying a restaurant shouldn't be vegan-only because as a crappy cook, you want people to be omnivores. It wasn't a critique of Mailbox as an app (which the author actually seems to like), but a critique of the choices Mailbox made.
critics: stop telling us how to do our jobs. perform sigint yourself if you feel so strongly.
-- The NSAespecially when your site is so weak - can't even handle HN visitors (5-7k users is a very small traffic).
Mailbox is a product made by Gmail users targeting other Gmail users who want a specifically improved experience. They weren't targeting just generic "email" users. This isn't a flaw in their design any more than it's a flaw in the design of a Porsche 911 that it can't haul your new dining room set in the back.
As far as the popularity of Gmail email addresses vs. the influx of AOL email addresses in the 90s; it's apples and oranges. The flood of AOL email addresses was bad because it heralded many clueless people into the Internet who were disruptive to the established culture.
It's not inherently bad many people share an email domain. That's silly.
As far as the popularity of Gmail email addresses vs. the influx of AOL email addresses in the 90s; it's apples and oranges. The flood of AOL email addresses was bad because it heralded many clueless people into the Internet who were disruptive to the established culture.
It's not inherently bad many people share an email domain. That's silly.
The flood of AOL email addresses was bad because it heralded many clueless people into the Internet who were disruptive to the established culture.
Firstly, that's just plain elitist. The notion that the internet would be somehow better if clueless people weren't able to use it is ridiculous. Arguably the fact that AOL (and others) lowered the intellectual barriers to entry by taking an exceptionally complicated system and making it easy to understand was just a forerunner to today's UX revolution - taking complex, and consequently expensive, products and services and making them trivially easy to use is the USP of many, many start-ups. We don't say that Dropbox users are clueless when they choose not to manually configure file replication across their computers.
Secondly, as someone who was writing web software in the late 1990s, I can absolutely assure you that there were clueless people on every ISP. AOL was the biggest but the fact that someone had a non-AOL email account was not an indicator they were any smarter.
Firstly, that's just plain elitist. The notion that the internet would be somehow better if clueless people weren't able to use it is ridiculous. Arguably the fact that AOL (and others) lowered the intellectual barriers to entry by taking an exceptionally complicated system and making it easy to understand was just a forerunner to today's UX revolution - taking complex, and consequently expensive, products and services and making them trivially easy to use is the USP of many, many start-ups. We don't say that Dropbox users are clueless when they choose not to manually configure file replication across their computers.
Secondly, as someone who was writing web software in the late 1990s, I can absolutely assure you that there were clueless people on every ISP. AOL was the biggest but the fact that someone had a non-AOL email account was not an indicator they were any smarter.
> Secondly, as someone who was writing web software in the late 1990s,
That's well after the great AOL flood happened. Which was mostly on Usenet and mailing lists.
If you weren't there of course it sounds just like a bunch of jerks being jerks, but really it was pretty horrible. Once AOL gave out Internet access to all of its users, the signal to noise ratio on Usenet and many mailing lists went to crap. Usenet never really recovered and became mostly a place for binary distributions of questionable legality, rather than discussions.
In the long run of course more people on the Internet made the web what it is today, and for a short while it heralded cheap, high performance home internet (which then stagnated at least in the US.)
Look, the whole AOL thing is old news and I pretty much never bring it up unprompted. But the author brought it up. And he misunderstood why the flood of AOL addresses on the Internet in the mid 90s was a bad thing. It wasn't just because aol.com was ubiquitous. It was that the aol.com email address usually signified an ignorance of Internet norms, technology, etc.
Pre-AOL, most people on the Internet were either there because they were at a college (student or faculty), or because they purposely sought out a provider which usually wasn't advertised or widely known.
Really AOL is to blame for giving their users access to this new place without telling them any of the etiquette of that place. It's like WalMart buying country club membership for all of its customers without letting them know they need to step up their normal attire.
That's well after the great AOL flood happened. Which was mostly on Usenet and mailing lists.
If you weren't there of course it sounds just like a bunch of jerks being jerks, but really it was pretty horrible. Once AOL gave out Internet access to all of its users, the signal to noise ratio on Usenet and many mailing lists went to crap. Usenet never really recovered and became mostly a place for binary distributions of questionable legality, rather than discussions.
In the long run of course more people on the Internet made the web what it is today, and for a short while it heralded cheap, high performance home internet (which then stagnated at least in the US.)
Look, the whole AOL thing is old news and I pretty much never bring it up unprompted. But the author brought it up. And he misunderstood why the flood of AOL addresses on the Internet in the mid 90s was a bad thing. It wasn't just because aol.com was ubiquitous. It was that the aol.com email address usually signified an ignorance of Internet norms, technology, etc.
Pre-AOL, most people on the Internet were either there because they were at a college (student or faculty), or because they purposely sought out a provider which usually wasn't advertised or widely known.
Really AOL is to blame for giving their users access to this new place without telling them any of the etiquette of that place. It's like WalMart buying country club membership for all of its customers without letting them know they need to step up their normal attire.
Usenet didn't die because of signal to noise, it died because over the history of the internet people have been moving from communication to broadcast. (Mail -> Usenet -> Web Forums -> Facebook -> Twitter).
Each step becomes more like "One to Many" broadcasts.
Each step becomes more like "One to Many" broadcasts.
Err, no. Your analogy sounds great but doesn't hold up at all.
In fact, the percentage of people you'd reach in a given Usenet forum far eclipsed what you'd reach on most any web forum when people first started switching. And most people on Twitter don't have many followers.
It's not about reaching more people, it's about where the people you want to associate with are.
Yes, people did abandon Usenet because of the signal to noise ratio, and people abandoned web forums for the same reason nd will eventually abandon Facebook and Twitter for the same reasons.
In fact, the percentage of people you'd reach in a given Usenet forum far eclipsed what you'd reach on most any web forum when people first started switching. And most people on Twitter don't have many followers.
It's not about reaching more people, it's about where the people you want to associate with are.
Yes, people did abandon Usenet because of the signal to noise ratio, and people abandoned web forums for the same reason nd will eventually abandon Facebook and Twitter for the same reasons.
I can't speak about AOL because I never used it, but I imagine the parent is talking about how apps like Outlook killed email conversation threads. [Edit: apparently that's not what parent was talking about, but I'm happy to take the opportunity to rant about a pet gripe anyway]. Far from simplifying email, they took a fairly straight forward system and complicated it to the point that nobody understood how to use it any more.
Specifically, they made conversations almost impossible to have by making top posting of replies the default, coercing the user into a behavior model that was contrary to the best practices that had been established by users of email to that point. The predictable result of this is that people stopped bottom posting and conversation threads were made practically impossible.
I wouldn't be surprised if this is why forums took over from mailing lists. I also wouldn't be surprised if this is why Gmail became so popular, because it fixed a problem that should never have existed: it made conversations comprehensible again.
So while I wouldn't blame newbies for breaking email, there is definitely a strong correlation, and it's because of the inadequate tools they were provided with in those early days.
Specifically, they made conversations almost impossible to have by making top posting of replies the default, coercing the user into a behavior model that was contrary to the best practices that had been established by users of email to that point. The predictable result of this is that people stopped bottom posting and conversation threads were made practically impossible.
I wouldn't be surprised if this is why forums took over from mailing lists. I also wouldn't be surprised if this is why Gmail became so popular, because it fixed a problem that should never have existed: it made conversations comprehensible again.
So while I wouldn't blame newbies for breaking email, there is definitely a strong correlation, and it's because of the inadequate tools they were provided with in those early days.
I've never been sold on the bottom-reply. Sure, if you're new to the thread it becomes easier to follow from the last, but if you're following from the first message it's a pain to scroll down to the bottom of every message to get what's new.
I would say I haven't seen an argument to convince me bottom-replys are better, but I honestly have never really discussed this with someone who cared.
I would say I haven't seen an argument to convince me bottom-replys are better, but I honestly have never really discussed this with someone who cared.
Part of the etiquette of email, before gmail arrived and did everything for you, was that you elided irrelevant parts of email quotes. You don't leave the entire thread in situ; you only quote the parts of the message you are specifically respond to, or that are material to understanding the exchange.
The massive pile of shit problem is new to Outlook and Gmail.
The massive pile of shit problem is new to Outlook and Gmail.
Leaving the entire thread in was happening long before gmail.
So, bottom-first people are essentially don't-quote-irrelevant-crap people? In which case it would make sense to place the quote you're responding to above your response.
So, bottom-first people are essentially don't-quote-irrelevant-crap people? In which case it would make sense to place the quote you're responding to above your response.
I agreed with your first statement, but you lost me at the second and third. Only support Gmail and iCloud are red herrings for the real argument, which was that apps should support standards (in this case, IMAP) and not providers (Gmail, iCloud). As for AOL flooding the Internet with clueless people, for a lot of us without technical friends, AOL was our only gateway to the Internet. It sucked being in the garden, but it got us online, and eventually we broke free of the bubble. Sorry that we came for your BBSes, Usenet and IRC, but cultures change, and resisting that is a futile effort.
You are free to disagree of course, but it is not silly. Centralizing into a locked garden or into an established monopol-like platform has negative aspects to the field as a whole. Just look at RSS before the google reader shutdown and compare to now.
Trusting the whole email-communication to one company with a direct link to the NSA can't be a good idea. To foster that development with seemingly unnecessary restricting focus onto gmail is fine to criticize.
It is not like they had to choose.
Trusting the whole email-communication to one company with a direct link to the NSA can't be a good idea. To foster that development with seemingly unnecessary restricting focus onto gmail is fine to criticize.
It is not like they had to choose.
I am against Google replacing IMAP with their own API (and yes I know they aren't removing IMAP support yet.)
But as far as an individual app developer choosing only to support Gmail, or only support whatever. That's their choice. That's not supplanting an industry wide standard. The case of Mailbox is very different from say, Mozilla removing IMAP support from Thunderbird, or Apple removing IMAP support from Mail.app. Mailbox as designed from the beginning as a Gmail client. That's not a flaw in the design, it's the intended design.
If you want a more general purpose mail client, make one. Don't fault other developers who weren't intending on making that in the first place.
But as far as an individual app developer choosing only to support Gmail, or only support whatever. That's their choice. That's not supplanting an industry wide standard. The case of Mailbox is very different from say, Mozilla removing IMAP support from Thunderbird, or Apple removing IMAP support from Mail.app. Mailbox as designed from the beginning as a Gmail client. That's not a flaw in the design, it's the intended design.
If you want a more general purpose mail client, make one. Don't fault other developers who weren't intending on making that in the first place.
> If you want a more general purpose mail client, make one. Don't fault other developers who weren't intending on making that in the first place.
I can't make another mail client right now, I already have a lot of projects, and some others on my todo-list (like indeed a rss-reader). But you don't have to build something on your own to have the right to critize other things of the same kind. That is really just unnecessary rhetoric.
The point of the article still stands: That the intended design is just targeting gmail is exactly the point he critizes. It is not a flaw in a design, the flaw is the design. IFF it would have worked with imap as well, but even if not, it still would be support for a too strong player (in his eyes at least).
And note that it is an appel, an advice of what would be better for the internet as a whole. It is not a design critic in the sense of "there is a bug". The article is inherently ideological, and that is valid.
I can't make another mail client right now, I already have a lot of projects, and some others on my todo-list (like indeed a rss-reader). But you don't have to build something on your own to have the right to critize other things of the same kind. That is really just unnecessary rhetoric.
The point of the article still stands: That the intended design is just targeting gmail is exactly the point he critizes. It is not a flaw in a design, the flaw is the design. IFF it would have worked with imap as well, but even if not, it still would be support for a too strong player (in his eyes at least).
And note that it is an appel, an advice of what would be better for the internet as a whole. It is not a design critic in the sense of "there is a bug". The article is inherently ideological, and that is valid.
It's fine to criticize others for pursuing goals you think are actively harmful. Of course, nothing makes your criticism magically "correct", and everyone is free to have different opinions, but the fact that a design was intentional doesn't make it immune from criticism.
I agree with your main point. However, this
> one company with a direct link to the NSA
is a blatant misrepresentation.
If mafia (or whoever) wiretapped your fibers would you be fine with people describing you as "a person with a direct link to the mafia"?
> one company with a direct link to the NSA
is a blatant misrepresentation.
If mafia (or whoever) wiretapped your fibers would you be fine with people describing you as "a person with a direct link to the mafia"?
If the boss of a company eats lunch with the boss of the mafia, I think that would be warranted.
However, I meant it more in a sense that the mails will be accessed by the NSA, be it on Googles servers, on the transport between Googles servers (they tried to fix that though, didn't they?) or before. As a link on the level of the mails.
However, I meant it more in a sense that the mails will be accessed by the NSA, be it on Googles servers, on the transport between Googles servers (they tried to fix that though, didn't they?) or before. As a link on the level of the mails.
Do you have a source about the lunch?
Yes, the traffic is encrypted now, see e.g. http://techcrunch.com/2014/03/20/gmail-traffic-between-googl...
Yes, the traffic is encrypted now, see e.g. http://techcrunch.com/2014/03/20/gmail-traffic-between-googl...
I'm a GMail user. I'd like an improved experience. I won't be using this product. In the future, I may want to change my mail provider. Using this tool will lock me with GMail or Apple mail. No thanks.
That's not to say the web isn't being AOL-ized. How many firms do you see these days advertising their presence on Facebook or Twitter over their own website (over which they have full control), in the same way we used to see companies everywhere advertising their "aol keyword"?
The reality of "the cloud" is we're squeezing things back into a few giant silos.