Perception is everything, when you’re talking performance

1 comment · · Tagged: , , ,

A month ago I made a big call on Twitter,

That was in reaction to Facebook’s failed attempt at making a hybrid app for Android and iPhone that used HTML5… when LinkedIn, Google and others apparently have done the same, very well, and Sencha did something similar (although not perfect).

I felt like I had to back it up.

I started this blog post a month ago too, but it was hard to put into terms what I was thinking, until it hit me what the worst complaint I had about Facebook’s apps.

It always looked slow.

You loaded the app, you got told it was Loading. Go to the Newsfeed, Loading. You see a notification waiting for you, tap that… Loading. Read a comment, Loading. Loading. Loading. All the time, you get hit with the Loading screen. And it’s no better even in the latest all-native apps. They’re still Loading, Loading, Loading.

I learnt while working on Trade Me Touch that faking speed is just as good as having real speed.

What I mean when I say Perceived Performance is when the app preempts you, it’s aggressively caching everything, it’s loading but you’re doing things anyway that make that wait not noticeable.

iOS on the iPhone and iPad utilise this to the max, especially on the apps that come with it (because they have special things they can do that other apps cannot). You load the Mail app and it looks like it’s ready to go right off the bat. It isn’t, iOS lies to you. When you apparently close a built-in app on iOS, it takes a snapshot and uses that as its splash screen. You may have caught this when you go scroll through that list of emails but you cannot, it’s because it made you think it was ready to go, but it wasn’t just yet.

In fact, how often do you even see a built in app on iOS say the words “Loading”? When you, pull down to refresh in the Mail app? Load a web page in Safari? The fact is, iOS appears fast because it is appearing fast. That’s not to say it isn’t actually fast, because it is actually fast… the perceived speed merely blends it.

So how does Trade Me Touch appear to be fast?

  • It’s caching your user profile, so it still has something to show on the homepage… it’s not 100% accurate information, but it was at a time and it isn’t necessary to be 100% accurate all the time. It will refresh this in due course of loading the homepage. Just not immediately.
  • The reason why Browsing the category tree is fast is because it’s already preempted you. It’s already downloaded all the templates required, it’s already downloaded the category tree. It’s simply grabbing the two from memory and mashing them together (it even stores that across sessions too).

These are just a couple of ways that made it appear to be fast. Now, if I was at Facebook, how would I have made the mobile apps appear to be fast?

  • Cached the living daylights out of all HTML+JS+CSS resources. You don’t need to redownload it all the time.
  • If you had Notifications or Friend Requests, preemptively download those information sets. Then when I click on Notifications, you don’t come across the Loading screen. If they still haven’t loaded, at least give the last set of Notifications so you can see if you missed any of them.
  • Remember information from one page to give to another. Something that Trade Me Touch doesn’t necessarily do just yet, but had a framework set up before I left. If I have a photo, surely I don’t have to reload the photo again on the next page?

Interestingly, Facebook the actual mobile web version does do some of the preemptive downloading. It just doesn’t do the aggressive caching. They just didn’t do it in the apps, which is strange. Also, not even the native app (at least for Android) does some of these things.

In short, use preemptive loading and cached assets to your advantage when working on mobile. Even on desktop you’ll get a nice performance boost. It’s not all about what you code, but how you code. Perception is everything.

A fresh lick of paint, a new travel blog

No comments · · Tagged: ,

One of the things you may have noticed recently is that the look of the blog has changed… again. However, there’s a new link up the top there… Travelling?

Yeah, I’ve left the country, and travelling about. So I’ve got a travel blog. Those posts don’t end up on this part of the blog, but they are all part of the same one (so if you subscribe to RSS, you will see them).

Those who go to the Travelling side are presented with some cool stuff. But this half of the blog is on the technical stuff, so how does it all tie together?

Location

The location is derived from the Google Latitude public widget. It uses a JSON request, and I have a cron job that requests this and stores it in the database. It only ever checks the location twice a day, so I may check in on a location in a day (although Android 4.1 seems to automatically do this for me without having to do anything) but it would probably never get picked up. I then use the Google Maps Static API to show this to you in a nice map.

The location is only ever shown at a city level.

Here’s a blog post from Miha Rebernik on how it’s done.

Social integration

One of the things that the blog is meant for is… well… me. So keeping a record of everything I’ve done social media wise is important as I tend to use Twitter as a micro-blog.

I use Picasa for photos, Twitter for micro-blogging and FourSquare for places. These are all sucked in using the If This Then That service. I’ve set up a couple of recipes (Picasa’s is using the RSS feed) to automatically insert new blog posts from them. It’s not instant, but happens roughly every 15 minutes.

This also means I can add other social networks with ease using one of the templates I’ve got (blog, tweet, photo or place).

Google Latitude seems to record the time I was first checked in to the city, which is great. So that means I can tweet about being in Bangkok, even though it still says I’m in Mascot, and then when the cron job runs and picks up that I’ve changed, the timestamp is recorded and all those tweets and posts move with it. It’s kinda automatic.

Using LESS

This part of the site also uses LESS to do the stylesheet, which is why it loads into place afterwards. The reason for that is… I ran out of time to fix it all. That’s the same reason why the alignment on the mobile version is a little bit off (but usable none-the-less).

WordPress comes into play

Then, they are all under a category called Travel, and it uses a specialised category template to show them all together. The specialised template actually changes the way that WordPress queries for posts, so that it’ll show the archive by location (not month, day or year), but only in this section.

I was hoping to have much of this as a WordPress plugin, but I didn’t have time (also the travel blog was more going to be a massive wall of images and text, but again, not enough time).

Anyway, off I go to do more travelling. The blog will once again be my little side project for programming experimentation.

June Conference Bonanza NZ Times

No comments ·

Because I live in New Zealand, and I’m interested in these things, I converted the times of the major conferences on this month into NZ Time. Yes, there are a lot of them.

E3 all these can be watched here

  • June 5th
    • Microsoft – 4:30am
    • EA – 8am
    • Ubisoft – 10am
    • Sony – 1pm
  • June 6th
    • Nintendo – 4am

Apple WWDC – keynote starts 5am June 12th

Microsoft Windows Phone Summit – (June 20th PDT, not sure of when it starts)

Google I/O 2012 – keynote starts 4am June 28th

(Converted with WolframAlpha)

It wasn’t as obvious as you thought

2 comments · · Tagged:

Recently, I was reminded about a little feature that Windows 95 had to introduce an exciting new concept.

Although we think about these user interface elements as familiar today, at the time, they were radically different from how anyone had used a PC before. The Start button was so undiscoverable that, despite having the word Start right on it, bouncing “<– Click here to begin” text had to be added to the taskbar after early test releases so that people could figure out how to get started using the programs on their PC.

Windows 95 Start button - with words 'Click here to begin'

Source: Creating the Windows 8 user experience – Building Windows 8

Of course, the little message was removed, and 12 years later the label was removed in Windows Vista. It was replaced by the orb we see adorning our screen corners today (unless you’re not using Windows). While 18 years ago, Microsoft needed to tell us that a button labelled “Start” is where we clicked to “begin”, today it’s pretty obvious.

Today I heard this little quote,

But the iPhone doesn’t come with any instructions!

This isn’t true. At all. And I only got reminded of this recently when I completely wiped my iPhone to start from scratch. Not only does the iPhone come with a little flip booklet called “Finger Tips” (here’s a PDF of the version that comes with the iPhone 4S – yes, it came with your iPhone, go look in the box!), but the iPhone (and iPad) show little tip dialogs when you use them the first time.

iPhone Edit Home Screen message

Source: Home can I wipe my old Apple iPhone clean of data? – Ask Dave Taylor

There are some amusing articles out there about when these first appeared, people freaking out that it was so “un-Apple like”. Yet, there they are, and still in iOS 5.1! (Although, not quite as wordy anymore)

It’s not a question about whether or not the software is intuitive, it’s about the learnability of the software. You don’t remember them because they were clear, and quickly became second nature*. Instructions, what instructions?

To end, if a core feature is intuitive enough, but users aren’t getting it right away, it’s probably worth giving a single, short sentence to nudge them in the right direction (but only once, maybe twice). If a constant reminder is in order, then maybe the feature needs to be rethought.

* Alternatively, you don’t remember them because you watched so many iPhone videos/was so excited about owning an iPhone that you just ‘Dismissed’ any dialog that appeared

Introducing Simple OAuth.net – because OAuth doesn’t have to be that hard

No comments · · Tagged: , , , , ,

Recently I’ve been working on a site that needed to interact with another site via OAuth via .Net. There are quite a few .Net OAuth libraries out there, but they’re all needlessly complicated. For example, in DevDefined OAuth, you have to specify the authorization URLs with the object, and use all these weird objects to make a simple request.

And if you’re using a POST with a custom content-type (like application/xml) you’re screwed. What is this business?

So, in Simple OAuth.net, if you want to get an access token, you do this:

var tokens = new Tokens() { ConsumerKey = "key", ConsumerSecret = "secret",
    AccessKey = "key", AccessKeySecret = "secret" };

var request = WebRequest.Create("https://api.twitter.com/oauth/request_token");
request.Method = "POST";

request.SignRequest(tokens)
    .WithCallback("oob")
    .InHeader();

var accessTokens = request.GetOAuthTokens();
tokens.MergeWith(accessTokens);

After you have all your access tokens, and you want to POST, say, a status update, that’s easy too:

var tweet = "status=Hello%20world&trim_user=true";

var request = WebRequest.Create("https://api.twitter.com/1/statuses/update.json");
request.Method = "POST";
request.SignRequest(tokens)
    .WithPostParameters(tweet)
    .InHeader();

using (var stream = new StreamWriter(request.GetRequestStream())) {
    stream.Write(UrlHelper.Encode(requestString));
    stream.Close();
}

This came about because I kept complaining on Twitter about OAuth, and mentioned that OAuth libraries in .Net should just be extension methods off a WebRequest object. I got challenged to make it and open source it, so a couple of months later I did. (Thanks, John-Daniel Trask).

It provides some helper methods to get through the OAuth handshake (like GetOAuthTokens and Tokens.MergeWith), and it doesn’t completely abstract that process away from you. It’s something I dislike about many OAuth libraries, they all try to be all fuddy-duddy and hide the choicest bit of OAuth – the handshake.

So simply,

  1. Create a WebRequest object to your OAuth call.
  2. Set any Method and query string/form post sections.
  3. Start with .SignRequest() and pass in your tokens.
  4. Then finish it off with .InHeader()

BAM! Done, you have an OAuth signed request that’s ready to be used. Just call for the Response Stream like you normally would.

It is not a Portable Library unfortunately. It’s currently in progress when I have time (or you could do it, the power of Open Source!). It’s under the MIT License.

Get a Home gets an update

No comments ·

Version 24-09-2011 is live, and what does it bring?

Well, saying that, it’s the first major front-end release in a while. It’s a pet project, one that I make sure still functions, so recently there have been a few mishaps, both from Trade Me and Google… fortunately, I just needed to upgrade the calls to be all proper in the backend, and with Google I had to downgrade the maps (until they reverted the changes they made earlier this week). Since these changes, things have been working tickity-boo.

One of the first changes you’ll note is the markers have changed colour. Red with a square dot in the middle indicates it’s an open home upcoming, but yellow with a down-facing triangle indicates that it’s coming up in the next… erm… day. There are still time sync issues I need to resolve, one of those issues where I work on the code in one timezone, and the code runs in a completely different timezone. They should be tidied up shortly. The colours should even be distinctive for colour blind users too (even without the symbols).

The bigger change comes in with the info pane. More info, but using less space! Price, bedrooms and bathrooms are all at the top, followed by photos, open home times and the description. The rest of the details (including Agent details) appear at the end. Not only that, but todays open home time appears at the very top so you can quickly glance at it while out and about. The thing you’ll need to look out for is the change of the close button, it’s now a cunningly placed tab on the very edge. This is bigger, and should be easier to hit with your finger on iPad/iPhone/Android.

I had feedback asking for the zoom to stop happening, which is a fair comment as things get a bit crazy confusing when you click on something and suddenly you’re whisked into the middle of no where (a known bug). So, Get a Home will no longer take over your zoom

Meanwhile, if you have it bookmarked on your iPad homescreen, you might want to redo it as it now features a slick new splash screen. No longer do you have to look into the empty white space of no splash screen while the iPad loads in the cached stuff.

I’ve learnt recently that the appcache will take a while to tick over, so you need to either completely clear your cache in your browser, or wait patiently for up to a week before you get it. This shouldn’t be a problem in the future.

The web will rule the day, eventually

No comments · · Tagged: , , , , , ,

Back in 2006, Apple had announced the iPhone. It was slick, it was the combination of the iPod, a phone and internet connectivity. It was unique, it was touch based, and I’m pretty sure we’ll look back at the launch of the iPhone as one of the definers of technology for the next decade. Device makers had never built a device that is for personal use with such power, of course we had the Palm’s and Windows Mobile’s, but they were designed for business. For once, a smartphone was developed for your life, and with that, rolled in a new generation of touch-capable, internet-focused devices from all over trying to catch on to the pie.

Steve Jobs announcing the iPhone

One of the more curious aspects of this device was that it did what Apple does best… it stripped something and replaced it in favour of something else. While in the past Apple would strip out the floppy disk drive in favour of a CD drive, and these days the DVD drive in favour of the web, in this case they stripped out native applications in favour of web-based apps.

It didn’t last long. The developer community was unhappy that they couldn’t get direct hardware access, invented the term “jailbreaking” and launched Cydia – your iPhone hackers app portal. For Apple this meant the web to take a backseat while things got sorted out, and in rolled an official SDK and an App Store in 2008.

Here we are 3 years later, and what has happened? Well, we’ve got iPads now, and the rise of the “web app.” But not quite where it should be. Thanks to Internet Explorer 6 (and other reasons), the internet is 10 years behind. HTML 4 was released in 1998, and it took a separate working group to develop the next iteration, HTML 5. It’s almost ready, almost. But HTML 5 doesn’t just need the semantic markup, it needs the APIs to access hardware, and for the first time in a wee while, we’re seeing rapid development in this area.

HTML 5 LogoThanks to the likes of Google, Mozilla and even Apple, we’re seeing some fantastic work being done. You can now access the GPS and the accelerometer. You can have up to eleven fingers of touch input (on iPad and iPhone, and Android 3.x). You can have hardware rendered special effects that run silky smooth. Soon, Android browsers will have access to the camera via HTML 5′s Device APIs. Chrome now enables C/C++ applications. The web standards today are being just as dynamic as the web it’s trying to deliver.

The web isn’t suited to everything, and that’s the case even on the desktop. On the desktop the native application is solving what I’d consider niche problems now. When was the last time you saw someone running a native mail client? The only people who would are running Outlook where email and communication demands are not the same as your general consumer. Games and music players are other examples, however music is already floating up in the cloud thanks to Last.fm and Grooveshark.

Native apps on mobile are sure to do the same… eventually the web will win out and native apps will solve niche problems that the web can’t solve (but may take a couple of years to get there). The current wave of native apps are pretty much a stop-gap. The argument that people expect a native experience all the time is a farce, people are more accepting of differences and quirks more than some realise. Look at the iPhone app landscape – everyone is banging on about “native! native! native!” and then rave about TapBots TweetBot which looks like no other iPhone app on the store.

Is the demand for native apps for websites coming about because websites aren’t creating adequate mobile web experiences? If you look at Facebook, it doesn’t function quite right on the iPad, so demand for an iPad app grows (and is to be announced?). Something that can be solved by Facebook easier if they accept that using Facebook on an iPad sucks. Utilising touch in your website isn’t hard, if you have a photo scroller, use something like jQuery.swipe to add left/right scrolling when someone swipes their finger.

I saw one of my friends’ friends had an iPhone and asked her how she found it, considering she wasn’t the most computer literate person and didn’t work around technologists. She described it as “awesome” and that email on it was “amazing.” Looking at her homescreen however, she was using Gmail. Yup, the mobile version of Gmail’s website. It was adequate for her.

The only factor not in favour of using the mobile web is Apple’s curious decisions with its HTML 5 “App Platform.” Keeping homescreen apps one-step-away from normal Safari, not having any way to upload files (even just photos), and limiting WebGL to their ad platform. Still, it does have the better HTML 5 device support, it’s just the web app developers need to talk louder.

Some HTML5+CSS3+Touch experiments

No comments · · Tagged: , , ,

I had been talking on my Twitters about experimenting with HTML5+CSS3 with touch events a few times, so I thought I should share as someone out there might find these useful. I got my iPad to play around with touch, and it’s already given me a few ideas about what to do next.

The Canvas experiment was my first foray into touch events. Put your finger down, and it draws circles. Put two fingers down, it draws lots of circles. Put all 10 of your fingers down, and you have a storm of circles.

This uses the touchmove event to loop through all the fingers that are passed through the touch event handler, drawing a circle at each.

The Flick experiment was on applying CSS3 transforms and animations to make a nice smooth effect when you attempted to drag around a box. I’m planning on applying this to Get a Home for the photo pop-up.

Put your finger on the box and drag left/right. Let go and it’ll animate back to its original position. Not only is it using Touch events, but also WebKit Transition Events. Basically, in the touchend event, I apply the CSS3 “Transition” property – “all 0.25s ease” – and then remove the “Transform” property. It makes this nice effect that you’d be used to when, say, you don’t drag your finger enough to go further in a list, or even you are at the end of the list and get that bounce effect.

You can use them in Chrome, but you won’t get the full effect. Plus it appears that Chrome 14-dev is rather broken right now with Canvas. (However, while developing the Flick experiment, I found that Safari Mobile ran it better than Chrome-dev did).

Feel free to modify either as you see fit. There are a lot of effects you can play around with in the Flick experiment!

Use HTML5 offline caching to speed up your web app

No comments · · Tagged: , ,

So you have a fancy new mobile web app, it loads OK, but wouldn’t it be good if the user was in 3G they didn’t have to suffer longer load times? Or waste their bandwidth each time they loaded your large JavaScript? HTML 5 thought this needed rectifying, so in rolls the Web Application Cache.

The cache identifies files that need to be stored on the users device to use in subsequent visits to the site. Funny, you may say, that this is what the cache that’s built in your browser is supposed to do, right? Well… yeah, it doesn’t quite work that way. The benefit of HTML5 application caching is that you explicitly tell the browser to store bits and pieces, and it remembers it, seemingly forever. It also doesn’t even attempt to download those files again, unless either the cache changes or you tell it to.

Get a Home has just enabled this offline application cache support, so I’ll go through the steps I went through to add it in.

First thing’s first, figure out what you want to cache. When you want to cache a webpage, you don’t automatically get a free pass to cache everything on a webpage. As soon as you add support to your page, your site will break. That is unless you set it up correctly.

You then need a cache manifest. This can be any extension, it seems that some use .appcache and others use .manifest. It doesn’t matter, but what does matter is that it must be sent as text/cache-manifest, there is no way around it and if you use a shared host that doesn’t let you change MIME types then your SOL.

The file starts with the line CACHE MANIFEST, and then a list of addresses. These do not have to be on your server, you can provide a full URL to cache or just a relative path. There can only be one per line, and you don’t get a wildcard, nor can you specify a folder to fully download. As an example,

CACHE MANIFEST
style/style.css
script/getahome.js
image/logo.png
image/load-big.gif
image/logo-black.png

You do not need to include the page that is calling it. The page that you set the offline manifest on is treated as the master page and will be included in the cache regardless.

Let’s say you called this file offline.manifest. To add your cache, just add the manifest attribute to your html element, like,

<html manifest="offline.manifest">

Visit your site and, presto! Hey wait… everything’s broke!

Here’s the fun part, the browser will only ever load things explicitly set in your manifest file, unless you add a handy NETWORK section. This section will specify what to give access to no matter. In this section, you can specify folders. But you can also give it a wildcard to mean “anything and everything that isn’t specified in this manifest can be downloaded.” So our example,

CACHE MANIFEST
style/style.css
script/getahome.js
image/logo.png
image/load-big.gif
image/logo-black.png
NETWORK:
*

Now visit your site and, presto! It’s all working again! Kill your internet connection, and try, you’ll see your site still loads.

How do you get it to update? Simple! Add a comment below the 1st line, these start with a #. Change this every time, as the web browser will check byte-for-byte any changes to the manifest file when you go to the page (online). If it’s different, it’ll redownload everything again.

CACHE MANIFEST
# rev 20110531
style/style.css
script/getahome.js

Chrome’s inspector provides some good debugging information for offline applications. Hit Ctrl+Shift+I, and reload your page to see what it’s doing, including what events are fired and where its manifest is coming from. If you go into the Resources section, you can see what files have been downloaded.

If you wish to remove your application cache, Chrome provides a way, but you have to delve a little deeper. In your address bar, enter chrome://appcache-internals to get a list of apps that have been installed, and you can delete them individually.

One thing you may have noticed is that there is a little notification if the cache is set up on Get a Home. This is done by using one of the caching events, there are a few of them, but in this example, I’ll just use the cached event.

var cache = window.applicationCache;
if (cache) {
 cache.addEventLister("cached", function() { alert("Cached!") }, false);
}

That little snippet will throw up an alert saying that the site was successfully cached when it’s completed.

Note that this is best for single page JavaScript applications, not multi-page or those requiring lots of dynamic resources to function properly. You can’t stick an offline manifest on every page of your static site, as it’s likely it won’t function as you expect it to.

Now, one more gotcha before I finish. iOS. You’d think that Apple wouldn’t break something like a simple web view, but you would be wrong. If your application is Web App Compatible, the home screen version of your app won’t use the offline cache. It could be a bug, however it has been around since iOS 4.2, and iOS 4.3 doesn’t even allow web apps to use the speedier Nitro JavaScript engine.

Ironically, one of the best references for the application cache I found was from the Safari Developers Website. No word in there as to how to get the application cache working on home screen apps!

HTML Rocks also has a tutorial on application caching.

There was a slight service disruption

No comments ·

Get a Home and this blog will experience a little disruption as they switch servers. This has already been kicked off, Get A Home will regenerate with a new version with lots of enhancements, while this blog will die for a little while until I fix it. Patience!

And we’re done! The service disruption was mostly because I backed up the wrong database. Fortunately, GoDaddy provided a grace period so I could go and grab that. Phew! Now all hosted by HostGator (and domains with 1st Domains).