So let’s be succinct. There are only two things to be concerned with:

• Can a user find the application?
• Does it work great?

Can a user find the application?

Unless you have a massive established brand (hello, Financial Times) you have to go to where users are looking for you.

• They Google and find a website. If it’s very usable (so either the desktop version reflows well or there’s a mobile site) they’re done. If it sucks or the website advertises a mobile app (e.g. Meetup, IMDB, Yelp) they’ll go to the app store.
• They search the app store directly and find an app. If it sucks they know it’s not going to get any better, so they’re done.

This behaviour is determined by the end user’s habits and the OS. The end user’s habits will vary by user, but is guided by their history. So many people use apps (especially in the US) that it’s going to be hard to train them out of searching app stores. The OS is also going to promote App store searches as long as apps appeal to users.

Does it work great?

Short answer – native apps work better than web apps. Web apps are getting better.

If a user downloads an app and uses it, they don’t care that you created an Android version as well. They don’t care that there’s feature parity. They just care that it works great on their device. That means fast UI response. Familiar widgets. If needed, access to device hardware (camera, GPS) and offline functionality. That’s all available with native apps – and somewhere between difficult and impossible on mobile web apps.

Here’s the only contentious point. Wouldn’t it be nice if we could produce web apps and not have to pay the Apple / Android tax? Only have to create once and have it run anywhere? Yes, it would be lovely – this is absolutely a better situation for app developers. This will only ever happen if:

• Users quit searching app stores (because OSes stop promoting them, and because they know that websites work great on their mobiles anyway)
• Mobile sites are just as smooth and functional as mobile apps.

But can you get away with it yet?

• Can you drive enough users to come to you, if you’re not in the app store?
• Does it bother you if users who DO search the app store end up looking at apps that are competitors or repackaged versions of your web content?
• Will a mobile web application work well enough that shifting to native wouldn’t make a different experience?
• Are all your developers humping HTML5 and thumbing their noses at Xcode and Eclipse?

Halfway houses

There are wrappers available that let you code once in web languages and run everywhere. The two big ones are Titanium and Phonegap. They kinda work, but you’ll be dealing with bugs and weirdnesses from not just one programming environment, but two.

TL;DR

Using mobile web apps will happen, but we’re still way off. Native apps will cost more to build and work better. Mobile web apps will cost less and work less well (although this will get better over time). Most people will want native apps right now, but evaluate your specific situation carefully. Only you can make the right choice for your business.

They aren’t the only ones. Here’s Amazon, which has free super-saver delivery in the US for orders over $25:

This is an opportunity for an online store to delight users by saying, “You haven’t quite met the minimum spend for free delivery, but what the hell – we’ll give it to you anyway.” The sale goes through, users were pleased that you were nice to them, and they’re more inclined to come back next time.

Worse: completing it doesn’t get you a confirmation that you’re unsubscribed, or even that they’ll think about. I wanted to write “you smell like a week old fish” in each of the confirmation fields, but then I definitely wouldn’t be unsubscribed.

Original site

Every new tool for circulating information used a mental model similar to the previous one. Check it out:

• The typewriter was a replacement for writing. Both output to paper, but typing was neater. Memos were created and paper was pushed from desk to desk.
• The original computer + printer combination was a replacement for the typewriter. Both created typeset neat text onto paper, but computers allowed you to save and recall files at will. People still used the “memo” template in Word.
• Email took over from the internal memo. You had an inbox and outbox, same as the physical boxes that used to sit on a desk. Most people emailed a short note and attached a Word file, in the same way they would with real paper – a cover sheet plus a document.¹

For the non-dinosaurs amongst us, the paper model is obsolete, and we have a new mental model – the data was produced on a screen and will be consumed on a screen. Most people consume massive amounts of data from the web – that’s what we’re used to. By comparison, Microsoft Word is a poor tool for the job.

• It pointlessly splits up a document into pages.²
• It loads a document very slowly compared to a browser (which is probably already open.)
• One can only consume information on computers with Word installed. Browsers are installed on almost every computer.
• Smartphones are fairly bad at reflowing or even viewing text from a word document. However, they’re phenomenally good at doing this for a web page.
• Extending a document with active elements (e.g. a stock quote) is unusual and hard, so Word documents are almost never used as an up-to-date reporting tool. On a web page it’s bread and butter.

A solution

What will replace Word? I’d argue that the wiki is a natural successor – a collection of web pages (instead of documents) that can interlink easily and be read anywhere using the same technology we use to read everything else.

Why hasn’t it happened yet?

• Making a Word-like interface that creates documents is a hard problem – hard enough that noone has really solved it yet.³
• It’s impossible to get off Word, because work gave you a copy, because you’re used to it, or because you’re expected to read / create .doc files.

These problems won’t exist forever. We will get closer to solving the rich text web editor problem – it just needs to be good enough. We will have fewer people to send .doc files to, as products like Huddle and Basecamp become more popular. Most of all, the size of the opportunity provides massive incentive to anyone who can solve this problem.

1. In the mind of the user, the document attachment is where the information is. Ever seen emails where someone attached a screenshot that’s contained in a Word document? That’s this mental model in action.
2. It can however be useful as a reference, i.e. “it’s on page 4″.
3. Solutions like CKeditor exist, but they don’t work well enough. It looks lovely, but try living with it and you’ll see where the paint comes off. The only consistently good editors are very basic, like the text editor built into Basecamp.

Option one: links to new page

Having separate web pages for each page of content is original flavour.

• Pros: Gives you N pageviews instead on one (if you’re worried about that metric), works on non-JS browsers
• Cons: Slow, as a whole new pageload is required

Here’s an example from Tom’s Hardware. This shows how many pages exist, and also what’s on each (so you can just skip to the conclusions page, for example.)

Option two: one page, AJAX changes the view

Here, all of the content is loaded in the initial pageview, but the pagination buttons switch what’s displayed to the user.

• Pros: Faster than a new pageview
• Cons: More complex to code (if you’re rolling your own)

Here’s an example from YouTube, but you’ll also find this all over the web on most large sites. Start watching the video, and click the page numbers at the bottom to get more comments. You don’t get another pageload – not only would that be slow, it would interrupt the 80s goodness you’re hearing.

When designing these, there’s a problem. If your list of stuff is kinda short – great. But if you have a long list, you scroll down to the bottom, click the page 2 button … and you’re at the bottom of the second page, not the top. To put it another way, you’re reading item 1, item 2 … item 10, then click Page 2, and instead of looking at item 11, you’re looking at item 20.

There are some solutions to this – Disqus, which powers sites like Engadget, collapses the whole comments section and re-expands it so you’re looking at the top. Steam does some batshit-crazy scrolling of the page and list to get you back to the top.

Option three: Don’t use pagination

If you’re feeling bold, you can just let the whole page load with every list item.

• Pros: Easy to code, easy to understand
• Cons: Unworkably large pageloads for very long lists (e.g. user generated comments)

A hybrid solution is using a MORE link that appends the next page to the current one. The nice part is that the list now goes from item 1 to item 10, then item 11 to item 20, and so on – the list order is easy to interpret.

• Pros: Easy to understand
• Cons: Harder to create references to data (e.g. item X is on page N is now an invalid reference), your list can look weirdly long compared to the rest of the page

You can see examples of this on Quora and other sites.

Which one should I use?

First – if you don’t need pagination, don’t use it. Nothing is as easy as having the whole page in front of you. Consider what your pageload times will be without it, both on desktop and mobile. If it’s too heavy – either right now, or in the future when a thousand people have created comments – consider the hybrid solution. Can you append items to the current list? Remember that from the user’s point of view, they are reading down a page of text – make it as easy as possible for them to continue that reading.

WTH is going on?

Administrative processing is a massively vague term. What’s actually happening is that the Embassy is doing a background check on you. They don’t do it themselves – instead, they package your information and send it off to the FBI and other agencies, who are actually doing the checks.

How long should I expect to actually wait?

I waited 32 days for processing of my F-1. I waited 4-5 months for processing of my H-1B.

The London Embassy helpfully publishes the status of your application on their website. Even better – they don’t just publish yours, but everyone else’s information as well. So, I did some quick analysis on this data.

For everyone who’s still waiting (i.e. status = pending), here’s a frequency graph of waiting times.

(This analysis is based on data from 09.00hrs on 14th Sept 2010.)

This means that, for example, about 52% of people who are waiting have been waiting more than 90 days. If the speed of processing at the Embassy isn’t changing over time, this means that your chances of hearing something before 90 days is about one in two.

I’ve also heard that the 90 day mark is used as an internal check, i.e. the embassy themselves will start chasing various agencies for the results of your check around this time. I’d expect to see an inflexion point in the chart if this was the case, but the data doesn’t seem to bear this out.

Is there anything I can do in the meanwhile?

If you want to speed it up, to the best of my knowledge there is precisely bugger all that you can do. To quote the London embassy:

Please do not contact the Embassy while your application is being processed as we will not be able to assist you.

You can only do two thing that will yield you information for sure:

• Obsessively check your email
• Check the website if you’re applying through the London embassy

For some people (including me) that’s just not enough, and there is other stuff to do, but it’s all just a shot in the dark rather than anything definite. In each case, I’ll include what I did and whether it helped (spoiler: nothing helped for sure).

Your senator. Although this might seem strange to us Brits, you can contact your local senator for assistance. This is probably the most concrete and useful step here. Unsurprisingly, your senator isn’t required to assist you in any way, but you can ask. In my case, we contacted Senator Dianne Feinstein’s office. The money quote:

My staff will be happy to assist you in following up on the status of your pending name check if your case has been pending with the FBI for at least one year.

Our company lawyer drafted a letter to a contact of his in Feinstein’s office. This is one of the advantages of *having* a lawyer, although it’s certainly no guarantee. We did get a reply back, but by that time the case was already completed.

State department. You can contact the state department directly to find out what the heck is going on. There is a direct number floating around, which I won’t include for fear of inundating the polite chap I spoke to, but it’s around. I did this, and was told that my application was still pending processing (not exactly a revelation). However, they were able to look up my case, so I did now know it had actually made it out of the embassy.

Personal network. If you’ve lived in the states for a while, you may know people who can find something out for you. It turned out that I had an acquaintance at the DOJ, a friend whose colleagues knew some politicians, and a colleague whose wife’s mum used to work for the state department. All of them were wonderful, sympathetic and tried to help by contacting people they knew who might know something. Although noone was able to dig up information specific to my case, I did get back some useful advice (which is now in this blog post).

National Academies. You can fill in a questionnaire. I’m not sure if it helped, but I did get a followup automated email after I was approved to confirm that everything was received.

The embassy themselves. The 221(g) plainly says that you can’t call the embassy for any information until 90 days are up. I called on the 91st day, but it was absolutely no help at all.

Is there anything I can do to avoid this in the future?

If you’re lucky enough to be reading ahead and you’re a few months before your potential 221(g), keep reading. If you’re in the US at the moment, I understand that it’s possible for you to get a check run on yourself before you head out. It will take about 3 months, and your local police department & FBI can help you out with this. Once it’s done, administrative processing should go faster – plus, you can take the checking documentation to the visa interview and wave it at them to save everyone some time.

What should I expect to see when it clears up?

You should get an email, but it’s not guaranteed. I didn’t hear anything on phone or email once the processing had completed on the H-1B, but I did get an email for the F-1. Here’s the text of the email I received.

Dear Mr $applicantName,

Please submit your passport.

You must resubmit your passport via the Embassy-appointed courier service, Special Mail Services (SMS). Once you are prepared to submit your passport for visa issuance please contact SMS by telephone on 0870-950-1760 to arrange pickup of your passport and delivery back to you upon issuance of your visa. The courier service will not have any information about your visa processing.

Important Notice: Your application will take between 15-20 workdays to process once it has been received by the Embassy. Once processing is complete, your passport will be handed to SMS. A further one to two days should be allowed for delivery.

The Embassy cannot expedite your application once it has been received. Please do not call the Operator Assisted Information Line or email us concerning the progress of your application unless more than two weeks has passed since SMS collected your documents, as we will not be able to provide you with any information.

We strongly advise that you do not purchase any tickets for travel to the United States or make irrevocable travel plans until after you have been issued a visa and your passport has been returned to you.

If your travel dates have passed, you must submit a new itinerary. If you are planning to travel for the same purpose at a later date, we may well be able to issue your visa, however, if your circumstances have changed, we will have to do further processing.

Summary

Expect to wait. If it clears up quickly – thank your stars and head to the New World.

Please drop a note in the comments if this was useful or you have any other experiences that might help others.

Updated: I added in some extra information as I learned more about the process. My H-1B has been issued and I’m now back in the states. Best of luck to everyone waiting.

Here are some products that are close to the implementation model:

• The command line
• IRC
• Opening files with VLC

Here are some ideas that pull implementation closer to a mental model:

• An email inbox
• A desktop in your operating system
• Folder icons in Explorer / Finder / GNOME

It never occurred to me that the same could happen in real life, but here it is, from a gym in Birmingham, UK. This is a sheet that members use to refer their friends (presumably in return for a discount).

Should we do it?

Just because we can do a thing, it does not necessarily follow that we must do that thing.

People hold these two views about interface animations:

1. Take the animations off! They are slow and I want to concentrate on function – this crap just gets in the way!
2. I will put in animations because I can. L33t

There is a third way, which is this – make your animations useful. I’ll explain by showing an example of a site that lights the way, and a site that ballsed it up.

This site lights the way

bandize.com

Behold, Bandize.

As you click through the navigation links – Show / Tours, Accounting, Contacts and so on – the content in the lower box sweeps linearly. If you go from link 1 to link 3, you see the content from link 2 sweeping by quickly. The list of links is your map, and the content box below is your zoom into that map.

The animations directly describe how your control is related to what you’re seeing, and that’s good.

This site ballsed it up

widgetbox.com

Behold, widgetbox.

This is a really similar content discovery style – a set of links (the four grey panels to the right) that control a panel (content to the left).

But this time, there are a few errors.

• Firstly, path from navigation links to content doesn’t match the animations. The content animation sweeps linearly along to the right, same as Bandize – but the navigation links are actually arranged in a zigzag. Try it – it’s confusing as heck.
• The grey panels activate on hover rather than click, which makes it too easy to navigate by mistake rather than intention.
• There are two more ways of navigating through content (I circled these in orange above). One, a play / pause control that’s almost invisible, and second, iPhone style dots (that actually do map correctly with the content animation – they’re in a line.) Both of these elements are clutter.

Conclusion

Using animations is easier than ever, but be careful. Don’t add them for their own sake – make sure they are helping the user understand what’s happening and why.

A few tricks seem to be happening:

• A transparent proxy loads your requested images, but sends you a more compressed version of your image instead.
• On every pageload, a script tag to insert this javascript file is injected into the page header. This file allows a user to request the full quality images with a keyboard shortcut after pageload. Instructions are given with a tooltip on every image.
• All unnecessary formatting is removed from the page source, i.e. spacing, tabs and so on from the HTML.

Here’s what the compressed image looked like:

Here’s what the original image looked like:

How much bandwidth did this save?

Here’s what we know.

• In my very non-scientific testing, the extra compression seemed to approximately halve the size of the image delivered.
• According to the YUI people, average image pageweight is around 50% due to images.

Therefore, T-Mobile should be saving around 25% on every pageload. This comes at the cost of a slightly diminished user experience for users, maintenance costs for the proxy and script files (albeit minimal), and potential subtle brand damage (a user might perceive T-Mobile delivered internet as worse quality).

Option one: Use vi

The cleanest way to develop code on that box is to SSH directly in there, and use vi, but it’s not all roses.

Advantages:

• Great syntax highlighting
• vi is frighteningly fast if you know how to use it
• You can use the same environment from any laptop running os x or linux, and it’s instantly familiar
• You don’t even need to install any software locally

Disadvantages:

• vi’s learning curve

For newbies like me, watching someone who’s familiar with vi makes me feel like Emmy from Mannequin. (“Where did they hide all the musicians?”)

So, you could spend a long time learning vi, or try something else.

Option two: Use something else

If you’ve ever used Dropbox, you’ll know that having a remote filesystem mounted in Finder makes working with files super easy. Luckily, there’s some great OSS around to help you do just that. Here’s how to get started:

1. Download and install MacFuse from here
2. Download and install MacFusion from here

After restarting your mac, you’ll be able to mount both SSH and FTP servers right into your filesystem. Now, you can use your text editor of choice on the mac, directly working on the files you want to play with.

Advantages:

• Use any text editor you want (I use TextWrangler because I’m cheap)
• Use all your mac’s keyboard shortcuts

Disadvantages:

• You need to install some software locally, so you’re screwed if you have to move between laptops

Being a vi numpty, I chose this second path, and so far it’s working a treat. However, there is a bug in the current version of MacFusion (v2 final).

Macfusion Bug on sshnodelay.so

When connecting over SSH, you’ll note that the connection can’t be made. You’ll see a “remote host disconnected” error, and on examining the log in MacFusion, you’ll see this:

dyld: could not load inserted library: /Applications/Macfusion.app/Contents/PlugIns/sshfs.mfplugin/Contents/Resources/sshnodelay.so

The solution is to rename the file to something else. Head into Terminal, and type this:

cd /Applications/Macfusion.app/Contents/PlugIns/sshfs.mfplugin/Contents/Resources/
mv sshnodelay.so MOVED_sshnodelay.so

… and voila, you can now mount over SSH no problem! (source)