MikeW

iPhone apps start "instantly" because the os zooms a pre-drawn picture of the application onto the screen. Often it looks like the frame of the app but without the content.

If you have a dynamic picture you could save a snapshot of what's on the screen when the app was closing, save it, and use that as your default image next time it starts. i.e. the last email you were looking at. It makes the app feel even more responsive when starting up because straight away you see what you saw before you closed the app.

There may be other uses but that's the one that jumps immediately to mind for me.

The article is also a little bit of flamebait when it says hotmail is in part run on Linux. All parts of Hotmail run in Windows Server. They use Akamai for caching static files such as images - as do many Microsoft services. Akamai reports they use Linux though.

The Hotmail team are sniffing based on firefox version but if sniffing must be done, it should be done by gecko version instead which will then take the cross section of browsers. It goes to show the kind of uproar and community excluded when sniffing is done wrong.

Long answer to a short question: (It depends.)

Some things I've picked up from being a beta tester, to running betas, and working at a company that did betas from tens of beta testers to many thousands of beta testers:

- There are groups of people who jump from beta to beta, trying to get a free ride without having to pay for the software (always jumping to the next beta because it's "good enough" if it doesn't meet a high quality bar)

- There are those who go well beyond the extra mile and help shape the products giving insights we never thought of. Those people were worth far more than $25.

One of the teams decided they would give the final version of software worth hundreds of dollars to any tester who submitted one or more pieces of feedback. This worked to: - Help links between the testers and the company long term. - Was a fair way of rewarding anyone who at least found an issue or design flaw.

Managing a good beta community takes a LOT of time and resources. At the start of the beta I spent more time engaging with users though the bugtracker/email (which ended up establishing norms) than actual deving, but when I ended up with 3 or 4 testers who understood what I was trying to achieve and try out what I wanted - they were brilliant. So perhaps instead of trying to figure out who should get pro versions and who should not:

- Give anyone who gave you valuable feedback/real bugs the pro product since it's so cheap - but be transparent. Loads of testers feel involved (and feel they have the right) to something so if you are transparent about the criteria then they can be applied to everyone rather than "top" people. Beta tester revolts get ugly and cost so much time and goodwill. - Find some way of rewarding the top few testers who you have a good relationship with and help your development and product evolution.

Although just about every project has had completely different expectations, motivations and feedback loops so chop and change any advice to suit you. However in every project I was involved with: the testers felt part of a community so don't ruin that.

I've found that optical media like CD-Rs and DVD-Rs corrode over time. Many of the CD-Rs I burned over the last 7 years are unreadable now. Different media seems to degrade at different speeds. Beware of burning a DVD, storing it away for 10 years and trying to read it then.

It has been about 1.5 years since I investigated bug trackers, and the software packages may have grown features/fixes since.

In my mind the choice of bug trackers comes down to who is the intended audience for it. Is it used for tracking issues by just the developers, or do end users also have access to it (You need a straightforward reporting method - users get very confised)?

You didn't say if you want to use a web-based tracker, or a desktop based version.

Briefly some of my thoughts on some web based trackers:

- Flyspray - I discounted this because it didn't support custom fields at the time. A quick googling shows this feature is in development.

- Trac - Horribly confusing for my bug reporters. Has so many features that's easy to get sidetracked into other parts (such as wiki) and content sprawl. Difficult to theme if you have a standard layout for a public site. It has a very cumbersome flow from visiting the tracker to getting an issue filed properly.

- Mantis - At first it looks really ugly but I've been overjoyed with it. It supported custom fields like I wanted. It was SO customisable. A limited amount can be done through a GUI but there are an insane number of items that can be configured through the config file. A downside to mantis was the awful documentation.

Mantis does have some SVN integration if you're willing to dig through the source code and set it up manually. It's possible setup a SVN commit hook to automatically resolve bugs in the tracker that contain strings like "fixed bug 25" (again, customisable through regular expressions) or a bug is referenced in commit messages, that commit can be added automatically as a note to the bug. (This is in the manual)

I also really liked mantis security groups. It's very flexible when you look at the config files (useful if you have end users submitting say sensitive attachments and only want devs/admins to access it), etc...

My personal gripe with Code Igniter is that it doesn't have a built-in templating language (this is by design).

I absolutely love Smarty (smarty.net) and highly recommend it and have used it in many projects so far.

There have been attempts to integrate Smarty into CI but I saw a benchmark that showed that combination was unacceptably slow and won't scale well.

Perceived performance makes for a great user experience. Tricks where the developers took the time to look at the user interaction.

A web example may be here on news.yc when I upvote a comment, I see it's done instantly even though ajax wizardry in the background does it. Sure is better than doing a whole page refresh.

One perceived speed example I absolutely love is on the iPhone. Everything "feels" so snappy and fast when in reality it isn't much better than the competitors.

Applications can use an image of their UI - a default view while the device really loads the application in the background and then switches from picture to app when loaded. Combine that with the zooming effects and it FEELS like apps load instantly and makes me FEEL like I love the experience, even though I can't actually interact with the application for up to a second.

I think it takes a very good engineer to come up with these little tricks. Perceived performance has real world satisfaction benefits.

I switched to dvorak for a few weeks a few summers ago. Initially typing every single word was insanely frustrating, and it didn't get much better for me.

I've been using QWERTY for 18 years and I continue to stick with it simply because it's familiar and I'm surrounded by machines all day every day that don't allow me to change the keyboard layout. Alternating between keyboard layouts several times every day is just not worth the frustration for me.

The choice of signon system depends on the type of site you have. I want my users to be able to sign up and use the service as quickly as possible.

Picking usernames can be a major source of frustration, my current thinking is the signup box should be just asking for email address and password, and roll from there. Quick and easy.

A few years ago Microsoft stopped allowing third-party sites to use Passport as a signin to their sites (except partners). Although they allow it again, I would take that as a strong warning not to rely on a third party for signin systems.

Facebook ask a lot of questions when signing up. If I didn't have a FB account, I would't be inclined to use your service if I had to tie it to a social network signin (unless your service was a facebook application).

OpenID is a massive disaster. I spent an entire day as a user reading up on it and trying to signup and use my ID on multiple sites. The whole thing is terribly complex and confusing. Every site implemented it badly. Do you want to support OpenID 1 or 2? Do your users care?

Last week I spoke to a developer on a massive site (a hugely popular new-generation audio site) and we agreed implementing an OpenID container is far from straightforward. You have to support many different things and some sites still throw errors when using OpenID Delegation (allow you to use your own domain to signin).

Unless you have a very good reason to, I'd suggest to keep far away from OpenID until they get their act together.

To recap, I want to register for a new site as quickly as possible. Just prompt for an email address and password and save yourself and your users a lot of hassle.

Broken Links: There are many older links in the comments in the form of http://news.ycombinator.com/comments?id=<num>; which returns an error (like the many comments on this page).

Those old links really should be transparently re-mapped to /item?id=<num> instead.