I think the author is trying to say that we should build products on top of established, open standards. Or, where applicable and within reason, we should integrate them into our product. Allows our users to more easily integrate our products into their existing workflows.
AFAIK canvas is an open standard. the OP is like someone criticizing a website that chose to use canvas over svg to display graphs,because canvas isn't accessible. It has nothing to do with using Open standards or not.
No. You just must build your new things in such ways that your competitors can easily repeat them and your customers can easily migrate to your competitors.
Your competitors are going to "repeat" you and take your Customers anyway. If lock-in is your value proposition then you have no value proposition. Using open protocols allows your Customers to do interesting things with your service that you never envisioned.
You can easily create something new while embracing standards. You can open your app up to existing standard means of consumption like RSS, email, SMS, etc.
The problem is that you can't make (as much) money using standard means of consumption. Why would a company charge for access via a standard protocol when there is much more money to be made by walling up the garden and blasting advertisements at the inhabitants.
And sadly making money is the purpose of 99% of the companies out there.
So how do standards come about? Someone does something new. Which means it isn't a standard yet. Otherwise we would still be using 1980's technology "standards".
There are very discrete routes to standardization through the IETF, ISO, ANSI, etc - you submit proposals, get them vetted, etc.
Two examples would be HLS and DASH. HLS is a draft standard of the IETF proposed by Apple, but Apple has never pursued standardization beyond that. This effectively means Apple maintains complete control of HLS and can change it however they want while still passing it off as a pseudo-standard. DASH was made by MPEG-LA, mainly to continue forcing their patent ridden nightmare video codec down everyones throats, but they got through full ISO standardization.
The third wheel there would be Flash - not a standard at all, a proprietary streaming protocol that is only usable by Adobe. They have no intent to standardize, and no intent to open the tech up ever. That is the kind of vendor lock in the OP talks about. All three were "something new", but each one did something different. And when you are making a product, you could take explicit steps to document your protocols and architecture, or you could keep it all proprietary and user hostile and try to maintain maximal control of everything.
Another good example is messaging. XMPP is another IETF standard, Telegram is a proprietary server with an open protocol, while Skype, iChat, Hangouts, and Whatsapp are wholly proprietary. You can implement XMPP servers or clients, and clients and servers can interoperate (assuming the server lets you, Facebook uses XMPP but their server isn't a full implementation, so you cannot add non-facebook friends in the service, for example). Telegram lets you implement clients however you want, but the protocol is designed to only work with their messaging servers, so you would have to fork the protocol to have server independence from Telegram. The others are all black box protocols nobody else can interoperate with and have no documentation.
No, just don't be greedy and don't try to capture all the value you're creating. Using open protocols, you can let your users build stuff that you could have never imagined yourself, and guess what - that only means more users for you.
You realize any CEO that didn't capture all value that the company created would probably be sued into the ground by the shareholders for not maximizing the return on their investment ?
In other words, you'd be fired by idiots who don't give a damn about anything than their wallets. That's the problem with shareholders. As someone explained on HN recently, "share holding" periods are often stupidly low. Shareholders are in no way interested in long-term good of the company. So if as a CEO you end up in a situation where shareholders are forcing you to do things that are bad long-term, there were likely some stupid decisions made that gave them so much power over you.
But anyway, you can't have cake and eat it too. If you care only about maximizing shareholder value, then don't lie to customers that you care about providing them value.
> You cannot build a 60fps scrolling list view with DOM.
I simply do not believe that. I have no problems scrolling around the internet. And the examples they give (flipboard.com/@flipboard) give me no clue about what their problem with the DOM is. I find it really hard to imagine you couldn't do that in the DOM.
Their use model is specifically on mobile devices, and it is certainly true that many sites run absolutely abysmally on smartphones/tablets. While these devices are powerful, they're still weak compared to most of our desktop machines.
Flipboard spent an enormous amount of effort making a rendering to canvas platform, humorously to allow an "open" option aside from their app (which makes the complaint about it in the submission rather perplexing). I suspect they did a lot of analysis. And the DOM is notoriously slow, one of the reasons being that it is now a catch all/everything and the sink platform that has an enormous number of modifiers -- the flexibility that we hail is also what leads to engine slowdown. We need a new, simpler layout standard that simplifies all of the various sidepaths and diversions that got built into the standard.
I heard the same "argument" when Facebook went from HTML to native. Personally, I never attribute to expertise what adequately can be explained by stupidity.
And they're still native. Most users find it a much better experience, and the general experience with the wrapped browser Facebook app was horrendous. I'm not quite sure what your point is.
After Facebook went native, LinkedIn did some "why we went with HTML5" thing...and then not long after they went native.
You mentioned in another comment that you need to see a list that has troubles on your Nexus 4. I find it difficult to believe you use the web much on the device with such a claim -- I regularly use a Nexus 4, 5, 7 (2013), and I regularly encounter horrendous websites where the site is so grotesquely overloaded that scroll requests are acted on literally a second+ later.
I love the web. I endlessly evangelize the web. But it has serious, profound problems that its biggest champions had to completely work around or avoid altogether.
As an added bonus you get a real choice of languages and frameworks once you depart from "open" web that practically only runs on JS, HTML, CSS. Transpilation is a hack.
Not if some people are choosing to build apps and libraries in assembly. Websites using manually written JavaScript and HTML should be disabled to run on modern browsers.
As someone who spends almost every day working on mobile web stuff, I promise you - doing anything involving custom animations on scroll is awful. Because you have to hook into the onScroll JS event and change properties on the fly, the effect is usually janky at best. Particularly on iOS < 8, because it didn't fire onScroll events regularly.
Perhaps a bit naive - these companies that start by embracing open standards then pull back from them are just pulling a classic bait-and-switch, with a bit of freeriding off open-source efforts thrown in. They bootstrap their user base and arrive to market quickly by using tools built by others. Then once they grow and gain market and mind share, they can start closing themselves off, walling the garden.
And it's just business - it's a logical step for a profit motivated organisation. You're value is in your users and your brand. So you take steps to lock in your users, prevent third parties from using your services with through open protocols (which dilutes your brand). Nearly all the current crop of (once-idealistic) companies are at it. It's really time to start learning from history that you can't depend on private, for-profit companies to act in the common good - because doing so spreads the value around, and a company wants it all for itself.
Here's an idea: there should be a maximum number N of employees a company can have. This enforces companies to think about the greater good, because if you're in a company that is split because of size, you might end up in a different company. Also, a maximum on the number of employees stimulates the "modularity" of the market: large conglomerates with internal markets will not be possible anymore.
I'm not sure of all the repercussions, but perhaps we can start with N at a large value, and slowly (over several decades) decrease it, and see what happens.
I don't think the parent to your comment misunderstood the GP. I think he was making a valid point: that in order to pick the "right" value of N, you have to know what value of N will maximize the greater good. Unless you can do that, the proposed law does not make sense; and saying "I'm not trying to specify what the greater good is, I'm just picking a number N" does not change that.
Not explicitly, no. I drew an inference about what the GP commenter meant (or at least an obvious implication of what I think he meant). He's welcome to correct me if my inference was wrong.
I think the obvious repercussion is that business will do everything possible to avoid this threshold, whatever it may be, up to and including cannibalizing their margins. N=500, we have 499 people, do we hire one more or find a way to automate that new need or other jobs, even if it costs more than a human would?
Technology companies may be able to run with ~100 people. But how are you going to run a large hospital? The NHS in the UK employs more than a million people.
You were that guy promoting the "NHS internal market", weren't you? This is basically what happened: individual hospitals run by trusts, services contracted in. GPs responsible for allocating budgets. It hasn't made much of a difference beyond increasing the number of administrative staff.
This does not matter at all, because if the separate companies have the same owner structure (which they will have), the segregation will be just on paper.
Right. See, for example, how the fact that some of the more stringent aspects of French labour law only apply to companies with 50+ employees leads to lots of 49-employee French companies.
That's assuming that Search Ad Services by Google will have--or will be allowed to have--clients other than Google. And that, of course, is the entire point: to split a company up into what are technically smaller companies that, in effect, are just part of the head company.
"Can be" in some cases, yes. But in order for the proposed restriction on company size to make sense, it would have to be possible in every case. That's a much stronger claim, and one I find extremely improbable.
Well, we already know that the current form of capitalism isn't perfect either. So I don't think there is a need to prove anything for every possible case. Also, we can make exceptions when we get there (even though I don't believe they need to be made).
> we already know that the current form of capitalism isn't perfect either.
Sure, but the question is whether any proposed change will be likely to make things better, or worse.
> I don't think there is a need to prove anything for every possible case.
Maybe not, but it doesn't look to me like you've even considered what fraction of cases would lead to a net benefit under your rule vs. the current rules.
The moment such business stops being "idealistic" and makes that "logical step" is the moment it stops caring about providing value for customer - it reduces the value provided to monetize them better.
Well the saying goes - if you aren't paying for it, then you are the product, not the consumer.
People using twitter or google or facebook are not clients because they aren't paying. The clients are the people who pay those companies for valuable information and advertising space.
Just a nit-pick: "you are the product, not the customer". I think a "consumer" can be either. Further complicating the terminology, many sites where you're the product (and some where you're the customer) rely on you to actually be a producer of content as well.
The saying is full of crock - it presents a false dichotomy. You might pay and still be a product. You pay for cable TV but they sell you to advertisers.
> You pay for cable TV but they sell you to advertisers.
That's not quite right. You pay your cable provider for television service. The cable provider pays networks for their content (the networks are the "suppliers" in this case). Some of those networks also collect payment from advertisers, but that advertising revenue probably wouldn't go to the cable company.
Just because it is a saying, doesn't mean it is true. There are some things that are free (as in beer) and you are still not the product.
In the case where companies are selling your data, you are both, whether or not you pay for it. The companies still need to work hard to retain you.
Clearly for many businesses, walled gardens, avoiding "openness", works. That might be because they use it to create an artificial moat to protect their business (arguably LinkedIn here), or because it's the best way to serve their customers (Steve Jobs' argument, not saying I agree).
For customers, if the best experience is gained through a native app, then a native app makes sense from the company's point of view. This is why native apps took off in the first place, right?
Just because you or I believe in open standards and information sharing doesn't mean it's better from everyone's point of view.
Native apps and open standards are not mutually exclusive. On the contrary, there are ways to make the data exportable both on the app side and cloud side. The reason companies tend to go for their own protocols is mostly greed. "Because why should I support RSS if I can't monetize it?". That's basically exploiting the common good without giving anything back.
I don't think it's fair to describe that as greed. The fact that a business can't monetise a service it provides is a bad thing; if Twitter for example provided access to everything over an RSS feed, the first thing you'd see would be applications that simply stripped or refused to display advertising etc.
I don't see why it 'exploits the common good' to want to charge or monetise a service you provide.
Huh, access to Twitter's API is one of the reasons that Twitter took off, then they started locking that down, adding restrictions meant to destroy alternative clients, because advertising.
To me this is a breach of trust - i.e. the underdogs are all about openness, they're growing based on the goodwill of the early adopters, then once they get big, they forget about openness. Personally I couldn't give a damn about Twitter's need to monetize, they should have thought about that since the beginning, before promising things they couldn't deliver and growing based on the generated trust.
Twitter is not alone in this, there are many other offenders, including Apple and Google. And they should really pay attention to what happened in the past, because once you piss off a significant portion of the industry, you can only go downhill from there. Companies like Microsoft can testify for that and oh look, they are the underdogs again.
One of my favorite features of the RSS reader I use is that it can hook up to a Twitter list, effectively giving me back an RSS feed of tweets.
(Previously I'd been scraping together Yahoo Pipes or Google App Engine based things people had made, each of which would work for about six months before something finicky would break 'em...)
> I don't see why it 'exploits the common good' to want to charge or monetise a service you provide.
To charge your users, no, of course not.
To charge advertisers and make your users products instead of customers, that's where the problem is.
(And part of the problem is that users have become so conditioned to getting services like Twitter and Facebook and Google for free that the idea of having to pay for those services would shock them.)
As much as the tech world loves to hate Apple, walled gardens are a huge part of why their stuff 'just works'.
Suppose you want an app to play videos. If your app uses a custom format no problem. If you support an open standard, the file might not, it might require more processing power than you have, it's probably for a different screen resolution, it...
In the end tech people are willing to trade stuff breaking occasionally for flexibility, but most people flip out when stuff breaks.
PS: I think you can break it down as do you want a VCR to show a movie to your friends, or a VCR that gives you an excuse to tinker.
Nonsense. Why does Apple have their own plug format instead of supporting USB? Is it somehow better? Easier? Blatantly not. This is just vendor lock in, the opposite of the fundamental ethic of the Internet.
Apple's magsafe and lighting adapter plugs are far better than USB connectors. They are reversible and don't have tabs to break off on the device side.
If you look close at in the connector on this S5 you can see there are two separate 'tabs' that are rather fragile if you are not careful removing and inserting your power cable. I've seen these break on phones before.
While their plug can be defended on engineering grounds, I'd ask a different question - why lock down Bluetooth to Apple devices only? iPhones were perfectly able to exchange data with non-Apple devices until at some point they weren't.
You can still use iPhones with car's built in systems so it's not really Apple only.
If you mean accessories like wireless keyboards I think the same 'just works' arguments directly apply. There are lot's of terrable 3rd party products out there.
Apple's 30 pin connector was pretty much always superior - it could do Audio/Video output natively, and also had pins for media control,so other manufacturers could add media support according to one established standard. As for the Lightning connector - it's reversible. That's "better" enough for me.
I want a VCR that can play any VHS I have and that I can plug to any TV I can find - not something that plays only iCassettes on BananaCRT which is expensive and my friends don't have.
Okay. That's what you want. Some people think that iCassettes have better picture quality and BananaCRTs have better ascetics and they find the overall user experience of iCassette players and BananaCRTs integrates together better than buying a VHS deck and a TV from different manufacturers and having to figure out how to hook up the standard but confusing connector all by yourself. Those people get to buy things too. And if the market is dominated by products that cater to their wants and not yours, maybe it's because your wants are in the minority.
So, your happy with the VHS and don't need to play Beta tapes.
PS: Sounds like your happy with a walled guarden and want something that just works. Did you get a Blueray player or a conbo that also handels HD-DVD's?
Slightly different, I think. VHS and Beta were competing formats, but you could play any VHS tape in any VHS player. That was the point the parent was making, I think.
I wonder how much of that we owe to the fact that people were finding ways around region locking, and that DVDs were also used for software distributions.
You just can't prove that... Maybe because is by far not true.
For example, you can create an app that only uses LAME + VideoLAN encoders and supports two of their formats, MP3 and MPEG4 nothing else, cause you're sure those work on the hardware you're building, that's exactly what Apple does, and Ubuntu, and Windows.
Just use your LOGIC how the hell is an open protocol the reason why stuff breaks? If everyone is looking at it and it goes through a lot more review than closed standards, they're the reason why we have the internet and how it works.
Contrary to what you believe on, Apple actually uses tons of open protocols and standards, they made Webkit what it is, that's free and open source, they still work on it as far as I know, they have their fair share of closed ones too, but open has worked for them pretty well.
HTML is an open standard, try writing a strict HTML browser that fails on non-standard pages and then surfing the web. There is a huge difference between using HTML files internally generated by a process you control and trying to read anything calling its self an HTML file.
The same applies to MPEG4 there are plenty of files that work on one player but not another. EX: Wait you also want to open an 8k MPEG4 file on a phone?
PS: I wish everyone that suggests open solutions actually needed to implement one. Generally, when people say open solutions they really mean leverage some huge chunk of code that someone else wrote, or let me leverage your hardware and software for free.
It doesn't, though. Apple hardware and software are fragile, buggy, and crash-prone. They beachball at the slightest provocation and destroy work with abandon.
And aside from that, well, "You're holding it wrong." If it only works for one narrow workflow, it doesn't work; it's a toy solution for a stripped-down toy problem.
I feel like I'm missing something. We should use open standards like WhatsApp, who actually use a proprietary protocol that just seems familiar? We should avoid creating custom technologies like Flipboard, who actually embraced the open Canvas standard? Let's reminisce about SMS on Twitter in 2010 when smartphones were exploding and SMS was likely no longer the primary mode of interaction... This all makes no sense.
Flipboard addresses the accessibility issue in their article. While moving to canvas limits it for now, at least they are making an effort to incorporate it, which is more than can be said for most sites.
They're saying "Whooshy effects are more important than disabled people accessing our app. We'll let those people in when it doesn't impact our fancy UI." It could definitely be worse, because they could ignore accessibility completely, but that doesn't make their approach good.
> They're saying "Whooshy effects are more important than disabled people accessing our app."
It's a world of trade-offs. There are contexts where accessibility is obvious more important than most other concerns -- the IRS's web site should obviously be as accessible as possible because everybody needs to pay their taxes. On the flip side of things, the point of Flipboard IS the UI. Flipboard is all about aggregating other people's content and providing a different user interface to it. What Flipboard is doing is it is taking limited resources and trying to allocate them, and they're choosing to focus on improving the user experience for the vast majority of their users. Is that the right choice? I dunno. But I don't think condescendingly referring to their focus on user experience as "whooshy effects" adds anything to the conversation.
The only concern raised about the new Flipboard in the post is "accessibility" being "eschewed", but afik text in canvas tag aren't encoded proprietarily. If screen readers don't work well with canvas tag then the fix should be making more screen reader friendly than criticizing its adoption.
It's not just the text. It's links and the overall structure of the document - the screen reader has no context for this. How does the screen reader know that what's on the canvas is a menu, and that you can tab to it and select menu items with the relevant keys?
True - and hopefully you'll keep that up with your new site/app once marketers, CFOs, and investors get involved, I think that's when things start growing walls and controls. As soon as someone mentions "monetization," hopefully it's only explored as charging your users a reasonable rate for a good service.
Pretty much any time someone mentions "monetization" they mean abandoning "reasonable rate for a good service" and "tricking users into paying more for subpar service" instead".
The whole talk about "monetizing" and stuff reminds me of 'dsirijus comment[0], "Any sufficiently advanced business model is indistinguishable from a scam."
I totally appreciate the point, and I think there's a certain amount of validity to it. Open standards and interfaces make it better and easier to consume data – in theory.
That said, there are complexities. Monetisation is the obvious one; if you have an app or service that relies on advertising—Twitter is the obvious example—then the first thing that you'll find is an app that strips your advertising out.
It also seems quite reasonable that a company like Twitter is entitled to payment by people who want to use the data they aggregate. Sure, they're not the publisher, but they do provide the infrastructure. We could hypothesise about replacing that with an open, peer-to-peer infrastructure, but nobody has done so yet.
SMS isn't an open protocol. So using it as an example of "what to do" is strange in and of itself.
This article falls flat because the author never defines what they mean by "open." SMS is a walled garden, it is controlled by the cellular industry in case the author missed that. Costs you actual cash money to use too (!) which might be a detriment to many.
I dunno, Instagram did pretty well for itself, despite being an (iPhone exclusive!) app at first. For a while, they didn't even have a web interface for viewing images, much less posting them.
This is far too naive. User Experience drives everything. If your open protocol is the best thing since sliced bread but it's too complicated for the audience who should be consuming it? It will die and an application with great user experience will take its place.
While I love open protocols and will use them as much as possible, at the end of the day I'm still going to do whatever it is that provides my users with the best user experience.
> Lack of open protocol implies that client choices will be essentially limited to what the service provider offers. This is bad user experience.
You're conflating the inability to develop for a protocol / platform for user experience. Having an open protocol can make a user experience better but it certainly doesn't have to.
I understand your point - the proprietary applications offered might be so vastly superior to any potential alternatives that would use an open protocol as to make the whole idea irrelevant.
But that supposes that all user needs can be met that way, which in a resource-constrained world cannot be true: the proprietary application provider will inevitably have to prioritize some classes of users over others. Those users whose needs are not within the functional scope of the application are going to find their experience quite horrible.
Only open protocols guarantee the potential for diversity that can cover provide all users with good experience - or with an experience at all...
> But that supposes that all user needs can be met that way[...]
No, it doesn't. Giving the user a good user experience does not mean it's the absolute best-end-all experience.
> the proprietary application provider will inevitably have to prioritize some classes of users over others. Those users whose needs are not within the functional scope of the application are going to find their experience quite horrible.
The problem you're outlining here completely applies to open source communities, standard bodies and companies (it has nothing to do with open versus proprietary protocols). Everyone has to prioritize things and certain priorities will not meet the needs of all users. I would also argue that users whose needs are not within the functional scope of an application...should look for an application that meets their needs as best as possible. Not everyone is going to have all of their needs met with anything.
"...Flipboard just announced their migration to full-canvas..."
Ha-ha-ha, awesome!
So it's open, but you are not practically allowed to fix inconsistencies due to compatibility (especially outside of turtle-speed committees) and you are also not allowed to do things own way?
No, no. You have to use a document-oriented mark-up to create GUIs and for business logic you have to use/compile to a legacy language flawed from the day one which cannot be fixed!
I don't like the shot at Flipboard here. HTML was designed for marking up (hypertext) documents. It's a perfectly fine language for marking up documents. It's a terrible kludge for defining application user interfaces, as anyone who has ever built such an application can attest.
What we're seeing now is a shift to JSON-over-HTTP from HTML-over-HTTP as the protocol of choice for connecting the internet, along with a whole pile of different tools for defining application user interfaces (partially because, up to now, no decent standard exists).
Not to mention that they open sourced their interface for rendering React on canvas, which is opens the door for more (smaller) companies to do the same. What they did is phenomenally friendly to the open source community.
Also Flipboard is no less accessible then it already was as a native application. The problems with making an app rendered in canvas can be solved (largely because they open sourced their work).
Your app might be better than an open protocol if the open protocol doesn't do what you want it to. RSS is great, until you want to add a feature that RSS doesn't include. And let's face it, if you tie your business to standards ratified by standards bodies you're going to need funding for the next ten years or however long it takes them to ratify something.
That's not what I mean. What I mean is that given two products -- one with an open protocol and one with closed -- very, very few customers will exercise a buying preference for the former.
> When Twitter was gathering steam back in 2009-10, it did so because tweeting was done via SMS and not over a proprietary interface.
I don't believe this for a second. In 2009-2010, there were already a huge number of smartphones and Twitter clients out there. In fact, that time was probably better for third-party Twitter clients than today. Smartphone growth exploded in 2009-2010, so the idea that "everyone was getting a featurephone" is complete bullshit.
Has anybody here ever even used Twitter via SMS? Desktop and mobile apps made Twitter. SMS was a niche thing at the very beginning.
I wouldn't even bother raising the issue if he weren't trying to premise his bigger point on it.
So that gets to his bigger point, which I'm not so sure about. Yeah, I can reply to Jira tickets from my email. But it's a huge pain. The replies end up with a whole bunch of email crap jammed into them, and it makes it harder to follow conversations. I usually edit other people's email responses to remove that stuff. So yes, it can be done. And maybe it's just Jira, but in this case at least, it's a much degraded experience.
Don't forget about Twitter's API and liberal usage policy that made the plethora of clients and mashups possible -- I think this accelerated their growth more than anything.
Their API is not so "free" now -- you need to register your app, always authenticate, and there's no public firehose access any more.
This is a far better point. Twitter happened along in that magical time of AJAX when everyone was willing to share their data because we all talked about how everything should be free and open.
Then the social media companies realized that this was a gigantic mistake, and started to seal everything up. How could they be expected to make their billions when their services were so open that they were essentially becoming abstracted protocols for third party apps? The opportunity to sell advertising and personal data is far greater when what you have is closed.
I understand why they did it; I just hate that they did. It always felt like a massive bait and switch and I'm betting that Facebook and Twitter aren't going to be the last ones that do this.
You're correct. Smartphone usage growth basically coincides with Twitter's growth, and early Twitter apps had far fewer constraints.
Twitterrific was a jailbreak app before Apple even launched the App Store. Did Twitter even have an official iOS app before they bought Tweetie? That seemed like it happened around the time of the first big API lockdown.
> Has anybody here ever even used Twitter via SMS?
yep :) I mean, both of our experiences are just anecdotal evidence pointing to each side of the argument. But in my experience, it made it easier to get onto the service.
Yes. Many people did. Twitter's success at 140 characters was largely based on being accessible without the high cost of a smart phone at a time when not everyone had an iPhone or T-Mobile Android.
I don't have any hard statistics, but I used Twitter before I had a smartphone; and you asked a question where an anecdote would suffice.
Well my real point was that SMS isn't what drove Twitter's growth, which was a major point in the article.
Twitter's growth coincides very closely with smartphone usage growth, in 2009-2010—well after SMS was the norm for connecting to it, if it ever was. SMS may have been useful early on, but apps certainly killed SMS usage.
When twitter first started out most people I knew were just starting to get smartphones. This is why things like text-to-twitter and twillio started off.
I would say by 2010, clients had taken over, but in 2008/2009 sms was really a thing.
134 comments
[ 3.2 ms ] story [ 215 ms ] threadYou can easily create something new while embracing standards. You can open your app up to existing standard means of consumption like RSS, email, SMS, etc.
And sadly making money is the purpose of 99% of the companies out there.
Two examples would be HLS and DASH. HLS is a draft standard of the IETF proposed by Apple, but Apple has never pursued standardization beyond that. This effectively means Apple maintains complete control of HLS and can change it however they want while still passing it off as a pseudo-standard. DASH was made by MPEG-LA, mainly to continue forcing their patent ridden nightmare video codec down everyones throats, but they got through full ISO standardization.
The third wheel there would be Flash - not a standard at all, a proprietary streaming protocol that is only usable by Adobe. They have no intent to standardize, and no intent to open the tech up ever. That is the kind of vendor lock in the OP talks about. All three were "something new", but each one did something different. And when you are making a product, you could take explicit steps to document your protocols and architecture, or you could keep it all proprietary and user hostile and try to maintain maximal control of everything.
Another good example is messaging. XMPP is another IETF standard, Telegram is a proprietary server with an open protocol, while Skype, iChat, Hangouts, and Whatsapp are wholly proprietary. You can implement XMPP servers or clients, and clients and servers can interoperate (assuming the server lets you, Facebook uses XMPP but their server isn't a full implementation, so you cannot add non-facebook friends in the service, for example). Telegram lets you implement clients however you want, but the protocol is designed to only work with their messaging servers, so you would have to fork the protocol to have server independence from Telegram. The others are all black box protocols nobody else can interoperate with and have no documentation.
But anyway, you can't have cake and eat it too. If you care only about maximizing shareholder value, then don't lie to customers that you care about providing them value.
> You cannot build a 60fps scrolling list view with DOM.
I simply do not believe that. I have no problems scrolling around the internet. And the examples they give (flipboard.com/@flipboard) give me no clue about what their problem with the DOM is. I find it really hard to imagine you couldn't do that in the DOM.
I wonder what is going on over there.
Flipboard spent an enormous amount of effort making a rendering to canvas platform, humorously to allow an "open" option aside from their app (which makes the complaint about it in the submission rather perplexing). I suspect they did a lot of analysis. And the DOM is notoriously slow, one of the reasons being that it is now a catch all/everything and the sink platform that has an enormous number of modifiers -- the flexibility that we hail is also what leads to engine slowdown. We need a new, simpler layout standard that simplifies all of the various sidepaths and diversions that got built into the standard.
I heard the same "argument" when Facebook went from HTML to native. Personally, I never attribute to expertise what adequately can be explained by stupidity.
http://techcrunch.com/2012/12/13/facebook-android-faster/
After Facebook went native, LinkedIn did some "why we went with HTML5" thing...and then not long after they went native.
You mentioned in another comment that you need to see a list that has troubles on your Nexus 4. I find it difficult to believe you use the web much on the device with such a claim -- I regularly use a Nexus 4, 5, 7 (2013), and I regularly encounter horrendous websites where the site is so grotesquely overloaded that scroll requests are acted on literally a second+ later.
I love the web. I endlessly evangelize the web. But it has serious, profound problems that its biggest champions had to completely work around or avoid altogether.
I said "minimal example". As Linus Torvalds puts it: Words are cheap, show me code.
Can't complain; their results do look gorgeous.
And it's just business - it's a logical step for a profit motivated organisation. You're value is in your users and your brand. So you take steps to lock in your users, prevent third parties from using your services with through open protocols (which dilutes your brand). Nearly all the current crop of (once-idealistic) companies are at it. It's really time to start learning from history that you can't depend on private, for-profit companies to act in the common good - because doing so spreads the value around, and a company wants it all for itself.
I'm not sure of all the repercussions, but perhaps we can start with N at a large value, and slowly (over several decades) decrease it, and see what happens.
What? No. The comment said nothing whatsoever about 'N'. GP's comment was exactly this, and nothing more:
How would you even start to define a term like "the greater good" in a way that a law like this could event begin to make sense?
Not explicitly, no. I drew an inference about what the GP commenter meant (or at least an obvious implication of what I think he meant). He's welcome to correct me if my inference was wrong.
These companies could then be hired by the hospital itself.
"Google? No, I technically work for Search Ad Services by Google."
Also, if you don't like what company X is doing, you just need to find N qualified people, and you can start your own X.
http://www.sonoma.edu/users/e/eyler/426/coase1.pdf
Sure, but the question is whether any proposed change will be likely to make things better, or worse.
> I don't think there is a need to prove anything for every possible case.
Maybe not, but it doesn't look to me like you've even considered what fraction of cases would lead to a net benefit under your rule vs. the current rules.
People using twitter or google or facebook are not clients because they aren't paying. The clients are the people who pay those companies for valuable information and advertising space.
That's not quite right. You pay your cable provider for television service. The cable provider pays networks for their content (the networks are the "suppliers" in this case). Some of those networks also collect payment from advertisers, but that advertising revenue probably wouldn't go to the cable company.
That explains all of the ads I see on GNU Emacs.
/s
Clearly for many businesses, walled gardens, avoiding "openness", works. That might be because they use it to create an artificial moat to protect their business (arguably LinkedIn here), or because it's the best way to serve their customers (Steve Jobs' argument, not saying I agree).
For customers, if the best experience is gained through a native app, then a native app makes sense from the company's point of view. This is why native apps took off in the first place, right?
Just because you or I believe in open standards and information sharing doesn't mean it's better from everyone's point of view.
I don't see why it 'exploits the common good' to want to charge or monetise a service you provide.
To me this is a breach of trust - i.e. the underdogs are all about openness, they're growing based on the goodwill of the early adopters, then once they get big, they forget about openness. Personally I couldn't give a damn about Twitter's need to monetize, they should have thought about that since the beginning, before promising things they couldn't deliver and growing based on the generated trust.
Twitter is not alone in this, there are many other offenders, including Apple and Google. And they should really pay attention to what happened in the past, because once you piss off a significant portion of the industry, you can only go downhill from there. Companies like Microsoft can testify for that and oh look, they are the underdogs again.
There already are Twitter apps for phones that don't display advertising.
(Previously I'd been scraping together Yahoo Pipes or Google App Engine based things people had made, each of which would work for about six months before something finicky would break 'em...)
To charge your users, no, of course not.
To charge advertisers and make your users products instead of customers, that's where the problem is.
(And part of the problem is that users have become so conditioned to getting services like Twitter and Facebook and Google for free that the idea of having to pay for those services would shock them.)
Suppose you want an app to play videos. If your app uses a custom format no problem. If you support an open standard, the file might not, it might require more processing power than you have, it's probably for a different screen resolution, it...
In the end tech people are willing to trade stuff breaking occasionally for flexibility, but most people flip out when stuff breaks.
PS: I think you can break it down as do you want a VCR to show a movie to your friends, or a VCR that gives you an excuse to tinker.
Apple's magsafe and lighting adapter plugs are far better than USB connectors. They are reversible and don't have tabs to break off on the device side.
If you look close at in the connector on this S5 you can see there are two separate 'tabs' that are rather fragile if you are not careful removing and inserting your power cable. I've seen these break on phones before.
http://images.anandtech.com/doci/8554/DSC_1380.jpg
The iphone connector has no small fragile pieces like that.
If you mean accessories like wireless keyboards I think the same 'just works' arguments directly apply. There are lot's of terrable 3rd party products out there.
So, your happy with the VHS and don't need to play Beta tapes.
PS: Sounds like your happy with a walled guarden and want something that just works. Did you get a Blueray player or a conbo that also handels HD-DVD's?
For example, you can create an app that only uses LAME + VideoLAN encoders and supports two of their formats, MP3 and MPEG4 nothing else, cause you're sure those work on the hardware you're building, that's exactly what Apple does, and Ubuntu, and Windows.
Just use your LOGIC how the hell is an open protocol the reason why stuff breaks? If everyone is looking at it and it goes through a lot more review than closed standards, they're the reason why we have the internet and how it works.
Contrary to what you believe on, Apple actually uses tons of open protocols and standards, they made Webkit what it is, that's free and open source, they still work on it as far as I know, they have their fair share of closed ones too, but open has worked for them pretty well.
The same applies to MPEG4 there are plenty of files that work on one player but not another. EX: Wait you also want to open an 8k MPEG4 file on a phone?
PS: I wish everyone that suggests open solutions actually needed to implement one. Generally, when people say open solutions they really mean leverage some huge chunk of code that someone else wrote, or let me leverage your hardware and software for free.
It doesn't, though. Apple hardware and software are fragile, buggy, and crash-prone. They beachball at the slightest provocation and destroy work with abandon.
And aside from that, well, "You're holding it wrong." If it only works for one narrow workflow, it doesn't work; it's a toy solution for a stripped-down toy problem.
It's a world of trade-offs. There are contexts where accessibility is obvious more important than most other concerns -- the IRS's web site should obviously be as accessible as possible because everybody needs to pay their taxes. On the flip side of things, the point of Flipboard IS the UI. Flipboard is all about aggregating other people's content and providing a different user interface to it. What Flipboard is doing is it is taking limited resources and trying to allocate them, and they're choosing to focus on improving the user experience for the vast majority of their users. Is that the right choice? I dunno. But I don't think condescendingly referring to their focus on user experience as "whooshy effects" adds anything to the conversation.
The whole talk about "monetizing" and stuff reminds me of 'dsirijus comment[0], "Any sufficiently advanced business model is indistinguishable from a scam."
[0] - https://news.ycombinator.com/item?id=8227941
That said, there are complexities. Monetisation is the obvious one; if you have an app or service that relies on advertising—Twitter is the obvious example—then the first thing that you'll find is an app that strips your advertising out.
It also seems quite reasonable that a company like Twitter is entitled to payment by people who want to use the data they aggregate. Sure, they're not the publisher, but they do provide the infrastructure. We could hypothesise about replacing that with an open, peer-to-peer infrastructure, but nobody has done so yet.
This article falls flat because the author never defines what they mean by "open." SMS is a walled garden, it is controlled by the cellular industry in case the author missed that. Costs you actual cash money to use too (!) which might be a detriment to many.
While I love open protocols and will use them as much as possible, at the end of the day I'm still going to do whatever it is that provides my users with the best user experience.
You're conflating the inability to develop for a protocol / platform for user experience. Having an open protocol can make a user experience better but it certainly doesn't have to.
But that supposes that all user needs can be met that way, which in a resource-constrained world cannot be true: the proprietary application provider will inevitably have to prioritize some classes of users over others. Those users whose needs are not within the functional scope of the application are going to find their experience quite horrible.
Only open protocols guarantee the potential for diversity that can cover provide all users with good experience - or with an experience at all...
No, it doesn't. Giving the user a good user experience does not mean it's the absolute best-end-all experience.
> the proprietary application provider will inevitably have to prioritize some classes of users over others. Those users whose needs are not within the functional scope of the application are going to find their experience quite horrible.
The problem you're outlining here completely applies to open source communities, standard bodies and companies (it has nothing to do with open versus proprietary protocols). Everyone has to prioritize things and certain priorities will not meet the needs of all users. I would also argue that users whose needs are not within the functional scope of an application...should look for an application that meets their needs as best as possible. Not everyone is going to have all of their needs met with anything.
WebDAV: GoodReader, Notebooks (Alfons Schmid), OmniFocus, Textastic, TouchDraw, Transmit (includes extension)
CalDAV: 2Do
Other recommendations?
Ha-ha-ha, awesome!
So it's open, but you are not practically allowed to fix inconsistencies due to compatibility (especially outside of turtle-speed committees) and you are also not allowed to do things own way?
No, no. You have to use a document-oriented mark-up to create GUIs and for business logic you have to use/compile to a legacy language flawed from the day one which cannot be fixed!
"Open"? Really?
What we're seeing now is a shift to JSON-over-HTTP from HTML-over-HTTP as the protocol of choice for connecting the internet, along with a whole pile of different tools for defining application user interfaces (partially because, up to now, no decent standard exists).
Historically not true.
I don't believe this for a second. In 2009-2010, there were already a huge number of smartphones and Twitter clients out there. In fact, that time was probably better for third-party Twitter clients than today. Smartphone growth exploded in 2009-2010, so the idea that "everyone was getting a featurephone" is complete bullshit.
Has anybody here ever even used Twitter via SMS? Desktop and mobile apps made Twitter. SMS was a niche thing at the very beginning.
I wouldn't even bother raising the issue if he weren't trying to premise his bigger point on it.
So that gets to his bigger point, which I'm not so sure about. Yeah, I can reply to Jira tickets from my email. But it's a huge pain. The replies end up with a whole bunch of email crap jammed into them, and it makes it harder to follow conversations. I usually edit other people's email responses to remove that stuff. So yes, it can be done. And maybe it's just Jira, but in this case at least, it's a much degraded experience.
Their API is not so "free" now -- you need to register your app, always authenticate, and there's no public firehose access any more.
Then the social media companies realized that this was a gigantic mistake, and started to seal everything up. How could they be expected to make their billions when their services were so open that they were essentially becoming abstracted protocols for third party apps? The opportunity to sell advertising and personal data is far greater when what you have is closed.
I understand why they did it; I just hate that they did. It always felt like a massive bait and switch and I'm betting that Facebook and Twitter aren't going to be the last ones that do this.
Twitterrific was a jailbreak app before Apple even launched the App Store. Did Twitter even have an official iOS app before they bought Tweetie? That seemed like it happened around the time of the first big API lockdown.
yep :) I mean, both of our experiences are just anecdotal evidence pointing to each side of the argument. But in my experience, it made it easier to get onto the service.
I don't have any hard statistics, but I used Twitter before I had a smartphone; and you asked a question where an anecdote would suffice.
Twitter's growth coincides very closely with smartphone usage growth, in 2009-2010—well after SMS was the norm for connecting to it, if it ever was. SMS may have been useful early on, but apps certainly killed SMS usage.
I would say by 2010, clients had taken over, but in 2008/2009 sms was really a thing.
"Open protocols power the web...RSS, SMS, plaintext-email, HTML5 - these are the easiest, fastest ways to get users into your system."
Then: "Flipboard just announced their migration to full-canvas"
Unless we have different understandings of what HTML5 is, I think you just invalidated your own point.