Kayak: We’re Very Sorry BlackBerry Users(kayak.com)
kayak.com
Kayak: We’re Very Sorry BlackBerry Users
http://www.kayak.com/news/we-re-very-sorry-blackberry-users.bd.html
32 comments
"Our website does work on the BlackBerry browser"
So the mobile website works with BlackBerry but not Android? Huh.
The minute you open the keyboard in Android some Javascript scroll thing freaks out and insists on hiding all of the page content on you. It's impossible to use and has been broken for months (both Android 2.2 and 2.3 on sub-4.3" phones). I had just assumed it was only intended for iPhone users and used Orbitz instead.
So the mobile website works with BlackBerry but not Android? Huh.
The minute you open the keyboard in Android some Javascript scroll thing freaks out and insists on hiding all of the page content on you. It's impossible to use and has been broken for months (both Android 2.2 and 2.3 on sub-4.3" phones). I had just assumed it was only intended for iPhone users and used Orbitz instead.
Hey, thanks a lot for the feedback! I work at KAYAK so I'll make sure this gets to the right people. I don't work on mobile but usually it gets QA'd on a plethora of devices but maybe they didn't hit your corner case somehow. If you'd like to give a bit more information such as specific device names or other stuff, you can reply here or just post feedback at:
http://www.kayak.com/feedback/form
All feedback always gets read and routed and engineers quite often reply to feedback from their area.
http://www.kayak.com/feedback/form
All feedback always gets read and routed and engineers quite often reply to feedback from their area.
I havent tested the kayak site, but I had problems with the page randomly scrolling when typing on android
the fix was utterly ridiculous and I have no idea as to why this fixed it, but it certainly helped
the fix was utterly ridiculous and I have no idea as to why this fixed it, but it certainly helped
body > * { -webkit-backface-visibility: visible; -webkit-transform: none; }I sent feedback via the form. Thanks for the link.
My uneducated guess is that the autocomplete box scrolling code doesn't handle the sub-4.3" screen resolutions. Devs would be more likely to prefer top of the line phones.
My uneducated guess is that the autocomplete box scrolling code doesn't handle the sub-4.3" screen resolutions. Devs would be more likely to prefer top of the line phones.
Oof, how is sub-4.3" synonymous with not-top-of-the-line? These ginormous phones are driving me nuts! I won't upgrade my Nexus One until a decent sub-4" screen (Android) phone comes out.
That would be the case with devs, although we do have some old phones lying around too I think. Anyway, thanks a lot!
Ouch. I haven't seen a lot of companies make announcements like these. Usually they build low-quality apps and just leave them to languish on App World. I've heard that it's actually more expensive to develop an app for them than other platforms? Does anybody know the relative manpower needed to develop for each major platform - iOS, Android, BlackBerry, Windows Phone?
Probably just one dev to maintain the platform, but it's more than that. You then have the business stakeholders, you have the QA resources, you have the designers, etc. When you add the whole thing up, it could be a resource drain. It's a lot easier to scuttle the whole thing than have to worry about it every time you want to introduce a new feature/design.
I use Kayak a lot. I don't know the quality in the US, but in Europe it is working great. But, I have never installed the Kayak App, why? Because of the insane number of permissions it is requesting, like getting my unique ID, my phone number, the right to call for me, etc. This just says: "I will not respect your privacy." way better than any TOS.
OT: This is something I simply hate from the Apps in general (on Android in my case), they request way too many rights for most of them.
OT: This is something I simply hate from the Apps in general (on Android in my case), they request way too many rights for most of them.
I think it's important to maintain a strong, usable mobile site that gives as much app functionality as possible. That way they won't leave their users helpless in mobile. And, who knows? Maybe that's enough.
jQuery mobile and HTML5 have the potential to significantly disrupt the mobile app industry.
However, the "App Store" model still retains significant strength in the fulfillment of delivery of content to the phone, meaning, someone can currently search for what they want, be given multiple options, and execute accordingly.
Maybe what the HTML5 and mobile community needs is "App Store" type functionality?
However, the "App Store" model still retains significant strength in the fulfillment of delivery of content to the phone, meaning, someone can currently search for what they want, be given multiple options, and execute accordingly.
Maybe what the HTML5 and mobile community needs is "App Store" type functionality?
> jQuery mobile and HTML5 have the potential to significantly disrupt the mobile app industry.
Maybe in the future. The PlayBook supports HTML5 apps and we pulled a jQM app from RIM's store because it was so unbearably slow. Another client just wanted a quote on "fully portable" app, I downloaded some that were built with PhoneGap+jQM and they were terribly slow, on an iPhone 4S.
Just two anecdotes, but what seemed reasonable in desktop Chrome has not worked out for us yet on mobile.
Maybe in the future. The PlayBook supports HTML5 apps and we pulled a jQM app from RIM's store because it was so unbearably slow. Another client just wanted a quote on "fully portable" app, I downloaded some that were built with PhoneGap+jQM and they were terribly slow, on an iPhone 4S.
Just two anecdotes, but what seemed reasonable in desktop Chrome has not worked out for us yet on mobile.
This is good to know. I'm currently wondering how I should handle the mobile version of a web app I'm making. I had thought that people could just use the web site, but it sounds like that's a little far fetched (I'm heavy on javascript, light on server scripting).
Of course, I could change that for the mobile site if I needed to, but then I have two things to keep in sync so I'd rather try to avoid that situation.
What about local storage? Seems like an app is the way to go for that.
Of course, I could change that for the mobile site if I needed to, but then I have two things to keep in sync so I'd rather try to avoid that situation.
What about local storage? Seems like an app is the way to go for that.
Way to make a stand kayak. This gives me confidence in my decision to not write a mobile app for the Blackberry. I wonder if more will follow this...
A couple thoughts here. First - I think most people know by now that Blackberry is going through a bit of a down swing. It's clearly the underdog - so what Kayak is doing here isn't particularly brave or leading edge.
On the flip side - they just signaled a huge opportunity for any entrepreneur who wants to write a travel comparison app - you no longer have Kayak as the competition.
On the flip side - they just signaled a huge opportunity for any entrepreneur who wants to write a travel comparison app - you no longer have Kayak as the competition.
Haven't looked into it, but supposedly with BB6+ you can make apps with HTML5/JS. I switched back from iPhone for the bold 9900. It's come a long way.
If you're not familiar, it's definitely worth checking out WebWorks (https://bdsc.webapps.blackberry.com/html5/). Even though it is advertised to work on BB5+ it's only really worth considering at 6+.
Also, definitely worth a look is bbUI.js (https://github.com/blackberry/bbUI.js/). It's still very much beta, but RIM are doing a lot of the UI hardwork for you; without it you end up with a white screen and have craft the UI yourself. It's a bit like jQTouch for BlackBerry.
Also, definitely worth a look is bbUI.js (https://github.com/blackberry/bbUI.js/). It's still very much beta, but RIM are doing a lot of the UI hardwork for you; without it you end up with a white screen and have craft the UI yourself. It's a bit like jQTouch for BlackBerry.
Hi edlea, how flexible/complete is it in terms of API compared to native Java? (RIMlets) And how's the performance of the resulting app? (e.g. is it sluggish like PhoneGap's?)
Thats about as subtle as they can be about it.
[deleted]
I find it comical that they're still maintaining development for Nokia of all brands.
Nokia had 13% of the smartphone market last quarter, putting it third behind Apple and Samsung.
Hasn't Nokia abandoned Symbian in favor of WP7? Presuming they have, wouldn't developing for that platform be the same as spending resources to come out with an app for SideKick?
But, you build (and support) for the market that exists today, in addition to preparing for the market that's coming tomorrow. I think Kayak is saying that they believe Blackberry is neither.
No. They are in the process of doing so, but they still make a _lot_ of Symbian devices. Nokia had 13% of the market last quarter; WP7 only had about 1% of it.
Android in a BlackBerry Bold case, with BB inbox, email, IM, BBM, text entry, autotext, profiles, auto on-off, holster support, and stock Android for everything else. I would buy it in a heartbeat, if such a thing existed.
Why would it need to be a BlackBerry? Most (all?) of that stuff works or could work (if BlackBerry wrote it) on standard Android.
Big takeaway seems to be that Windows Phone is taking over BB as the third ecosystem.
We’re Very Sorry BlackBerry Users vs We’re Very Sorry, BlackBerry Users