Comment Re:No kidding. (Score 1) 259
So is a web browser, which is exactly my point.
So is a web browser, which is exactly my point.
That's why I don't want every random site creating its own app. When I said those words, it was in the context of a general-purpose mobile app, not a niche app for a single small website.
Web browsers on mobile devices don't provide facilities for downsampling the images, though, which makes standalone apps rather useful for sites that rely on photo uploading over slow cellular connections.
Sure there is. That's exactly what RSS [wikipedia.org] was made to do. Not only can you visit a site, get a feed, and add it yourself, but there are also applications that curate and categorize popular RSS feeds so that you can search for and add them without having to visit the websites first.
The problem is that RSS is one-directional. If I want to post, I still have to go back to a browser window and use whatever random, horrible, non-mobile-friendly interface the site designers came up with. And posting is usually the part where a native app would be beneficial; the reading part is easy by comparison....
And despite what you say, the facebook app is pretty much standard on every user's smart phone, and the app only shows content from facebook
...
... and is used exclusively by people who have accounts on the site. That's a completely different usage model than just going to a website and browsing it, which is to say that you didn't really contradict my main point with that example.
Facebook is also a bit of an exception because of the sheer amount of time that many people spend on it, the potential benefits of tighter integration with the operating system (background notifications), etc.
But for every exception, there are a thousand non-exceptions. Even though I have the FB app installed, I wouldn't really consider installing a Slashdot app; the way I interact with the site is completely different, with my FB interaction being a lot more active, and involving a lot more photo uploads and other such activities that web browsers do pretty badly in the mobile world.
During your rant, I couldn't help but think, 'But they DO have a standardized app for accessing all the websites', and it's called the browser!
The problem is, mobile devices don't handle web forums very well. Web designers don't design their themes with mobile devices in mind, resulting in text that's too small to read, text entry fields that are too wide for the screen, etc. That's not true for every site, but it is pretty common.
An actual native app, by contrast, is likely to be designed by people who actually understand the platform and its limitations, its screen size, etc. So potentially, if done properly, it can produce a much better user experience than a browser is likely to produce (though a browser could produce a similarly good experience if all the web designers took the time to design their sites properly for mobile devices... and I want a pony...).
Not really. My TV takes uncompressed data. Once an encoder is available, the only things that matter these days are whether the following things support the codec:
If you cover those, all other clients of the codecs are lost in the noise, so it is probably safe to use it on your own site for your own content.
It doesn't really matter at all whether the codec used to encode the content for delivery is the same as the codec used to encode it during production. In fact, I would seriously hope that 100% of video production is being done with a higher quality codec than the low-bitrate crap that is being used to deliver content over the 'net. Therefore, whether Mitsubishi et al choose to support a codec or not is mostly irrelevant.
In practice, only three companies actually need to work together to make such a patent-free codec happen: Apple, Microsoft, and Google. Firefox would quickly adopt any patent-free codec that those three got behind. That makes the entire rest of the industry pretty much completely irrelevant. Those three companies could mandate a transition to a new, patent-free codec, and the entire world would practically trip over themselves to make it happen.
So no, those industrial giants aren't really a problem. In fact, they aren't even relevant in the grand scheme of codecs except to the extent that the big three graciously allow them to be.
It is truly an epic fail to believe that some random visitor to your website is going to want to install your app just to read a piece of content—particularly if that user got there through a Google search. Yet for some reason, just about every forum out there pops up one of these idiotic app interstitials when I try to view some random post on their site. I didn't go there because I want to be a regular visitor to the site, which means I sure as h*** don't want to install their app just to read the tiny piece of content that may or may not even contain the information I need to do whatever I'm trying to get done.
The right time to ask a user to install an app is when the user creates an account on the site. Up until that point, the user is probably an infrequent visitor and is unlikely to want to install the app. Even at that point, the user may not want to install the app, but at least there's some nonzero possibility that he or she might.
Of course, the real train wreck is that there's no standard for making websites' contents available for app use, which would allow a user to install one reader that can read content on any of the dozen sites that he or she might be interested in. There's really no chance of me installing an app that only lets me read content from one website, because A. it is unlikely to be much better than viewing the website (because probably the same people designed it), and B. I already have more apps than I can deal with anyway. But if every website I visit standardized on a feed scheme, along with a common authentication system and a common reply system, I could see myself installing a single app that worked with all of them.
Don't like the licensing terms? Don't use H.265...
Better: Work together with like-minded companies to create a competing standard that is designed specifically to avoid patents, and license it royalty-free.
Obligatory xkcd.
I meant to say it's seen as unfair by the line workers.
It's not quite fair to exclude the cost of your ISP or wireless plan. Whether you "need it anyway" for other purposes or not, you still can't ACTUALLY get Netflix for only $12 month unless your ISP is free (and fast enough to support decent HD streaming).
Well, you can do their DVD service for $8, but yes, for their streaming service, you do have to have an Internet connection. Of course, if you have a smartphone, at least in the U.S., your cell service provider will likely require you to have a data plan anyway, so these days it's hard to not have a connection that you could potentially use for watching Netflix if you wanted to. (Whether that data plan would cost you more money if you watched Netflix all day is another matter, of course.)
Dress codes make a slight amount of sense when the company has a requirement that many employees must wear uniforms. It's not fair to say, "you people who stand in front of customers all day must wear a blue shirt, green tie, and khaki pants" but then say, "you people are in the main office, so you're exempt from dressing like a dork." Some of the line workers resent it. Management can then decide if they want to settle the matter by subjecting everyone to a dress code.
Of course HP doesn't require line workers to wear uniforms, so that's not the case here. This is just another stupid and capricious management decision by a company that's become famous over the last decade for having the most incompetent management of any (formerly) major corporation. HP's executives have been so bad it's easy to imagine an evil Michael Dell offered HP's board of directors one hundred million dollars -each- to sabotage HP into oblivion. (Hey, it makes a lot more sense than any other reason for imposing a dress code on engineers.)
Except Google didn't offer it to the public. It is an unpublished API that is and was unsupported for external use.
Is this the same API that Safari, Chrome, Firefox, etc. use for autocompleting search queries in their search boxes? If so, and if they disable it, there are going to be a lot of unhappy people, and by a lot, I mean literally every human being who uses a web browser.
The moon is made of green cheese. -- John Heywood
