Back up now. The cert was pointing to www.amazon.com, so it was throwing an error for amazon.com. Then, it would generate an SSL Protocol error. Very odd behavior.
The guy doing this review was only able to get 3.5 - 4 hours out of the battery. http://www.nomobile.ru/reviews/162216.html
Mediocre horizontal screen resolution for a 14" too
1600x900 on 14" is mediocre? Bear in mind that it's exactly the same size/weight as the 13" MacBook Air but has larger display (thanks to a narrower bezel on the sides), higher resolution, and an arguably better keyboard. Shame about the battery life, though. Also, considering they're using a carbon fibre shell, they should have been able to get the weight down to considerably less than that of the Aluminium MacBook Air. Sony got that part right with their own carbon fibre VAIO Z (lighter and with better display than either), but it has worse ergonomics than either the ThinkPad or the Air.
No product out there at the moment that gets everything right. The MacBook Air probably comes closest, although the battery life and TN+ display could both be substantially improved.
Note that the ThinkPad X220/X230 has both a better, IPS, display and can run for 12+ hours using a 9-cell battery whilst still weighing less than a 13" MacBook Pro. However, it's heavier than the newer slimmer notebooks and has lower resolution:
I was seriously considering purchasing this phone until I saw the comparison shots.
My first "Smartphone" was the LG Incite, running Windows 5.5 (I think?). It was absolutely unusable outdoors, at all. I can't overstate how awful trying to do anything outdoors with that phone was. Since then I've sworn I would not purchase another phone that was anywhere as bad in this regard.
Unfortunately it's pretty obvious the SIII is even worse than the SII, which I had.
I'm really glad now that I've jumped to the iPhone 4S after being a devoted Android fan for 3 years.
Sure, here's a screenshot of my hourly report for the past day. Note that the site hasn't gotten much traffic in general since most people come to it directly through the App Store — that is, despite pretty decent sales, the site has historically only had a few hundred hits a day.
Just for reference since a lot of people get this backwards as you did, i.e. is Latin for "which is to say" (literally id est, "that is"), while e.g. is Latin for "for example" (literally exempli gratia, "free example"). There is another cousin which doesn't get so much use, namely viz., literally vide licit or "clearly seen", which is a sort of drop-in replacement for "namely" -- it's used to enumerate or clarify an indirect reference, as opposed to id est which clarifies an indirect implication.
Wonderful tool! I've been doing this with the help of steer mouse and a clipboard history tool.
Maybe a bit to much to ask for, but how many sales are you up on now?
I just had a look at it, going back from a page to the listings gives a full second of a lag/black screen while the Top article screen is being recreated.
You truncate all the article titles. Don't do that, it means I can't read them.
I tried to create the app as closely as the mail app which does exactly the same with truncating, it is part of the Metro style. If you click on an item you will see the full item title.
I'll look into the animation between the item page and main page.
Building analytics from access logs is massively unreliable. I have a few domains that answer for http traffic but only serve "Welcome to nginx". When I tail the access logs I see thousands of requests from obvious bots, but also that traffic seems to be pretending to be other forms of traffic also.
There are some bots that pretend to be phones browsing around, IE, firefox.
Just remember that relying purely on access log analytics isn't something that will return accurate results.
I wouldn't call it massively unreliable from what I've seen so far.
For one it is offset by the fact that the site it is used on is Ajax'ed, so it is fairly simple to filter out those who poll just the container page and don't follow up with querying any actual content. For two, I'm getting good at detecting bots by simple filtering by User-agent strings and IPs. So it is far from the picture of an utter disaster that you describe.
Wonderful. I recently built a Facebook iFrame app and burned so many hours trying to make my app look vaguely inline with what a user expects a facebook. This is absolutely the perfect kit for that. It's a really terrible reflection on Facebook that they didn't provide exactly this themselves.
Every other "platform" provides UI guidelines with libraries/frameworks to allow others build products native to their platform. Facebook have made no good attempt at this, which is why this is a great project!
I'm going through this now so I'm equally excited. A little bit off-topic, but how did you deal with the back button problem?
Currently, if my user navigates a few pages deep in my app and clicks the back button, it exits the app and goes back to Facebook. Quite annoying... Thanks!
Because the app is in an iFrame, you can just use regular linked files and then the back button works as expected.
If you do that though, there are a few other issues - you may have to account for pages that do/don't have the Facebook signed_request post data - i.e. you probably need to store it in a session or cookie (and deal with the relevant IE7 cookie + iFrame issues by settings P3P header if you support IE7. Can't remember offhand if it is a problem in IE8.)
Obviously more complex apps where navigation is handled through AJAX get tricky when you can't access the container frame. Maybe look into history.js (https://github.com/balupton/History.js/) and see if it works in a Facebook app?
History.js looks promising. I'll definitely dig deeper. Using regular A tags does not work, however, hence my question.
I decided not to support IE7 since this is a brand new app. It will be IE8+. I had to deal with the P3P issue in the past and it was a pain. Hopefully IE8 isn't as picky.
Thanks for the help! I now have something to investigate.
I had trouble doing just this, mainly because of how IE handles cookies on 304. I used this Gem for a Rails app (~1 year ago): https://rubygems.org/gems/rack-p3p.
You could do something hacky with pushState [0], but it would take a considerable amount of work to make it work. I can't even think of a way to implement it, but you could try something out.
Your other option is to have a back button in your iframe in a prominent location and hope your user uses that instead of the browser back button.
If you somehow figure out a way to make pushState work, you should probably still have a back button in your app, for old browsers. Or at least display it for only old browsers.
Facebook actually passes the path from the canvas url to your iframe. So what I do is make all the targets "_top" and point to my canvas url. No need for complicated JS stuff. :D
As the developer of a couple of Facebook apps, I have to ask: do apps HAVE to "look inline" with Facebook? Is there any proof or anything showing that apps that use the same typography and style as Fb instead of their own visual style fare any better?
My poor Violin cost less than USD $100, you really ought to have got a very nice violin for USD $2500! If you still have it, it might be worth examining it and looking for a better resale value all these years later.
