5 Mar 2006

Stealth AJAX

Reading this article on stealth form submissions using AJAX got me thinking... we all know how dangerous that can be!As the article explains, an unscrupulous Web developer could employ AJAX in order to send the values of Web forms back to the server - even if the user does not submit the form. Of course, this technique could also be used to help the user - for example Gmail uses it to offer an auto-save feature.If you have an online application form, probably one of your biggest concerns is drop-out rates. The larger companies go to great lengths to ensure the usability of their application forms as a result of this, with the goal of reducing drop out rates. Vast amounts of money go into tracking solutions which can pinpoint where a user drops out, and that data can (hopefully) be used to ensure that other users do not drop out at the same point.So, I'm the CEO of a credit card company (I wish!), slightly concerned about drop out rates. I call my underlings into a room and proudly announce:
"Lets use this AJAX thing on our forms. That way if a customer drops out then we can still harvest their e-mail address and can entice them back!"
Aside from sounding more technically literate than most CEO's, I've got a good idea, however there is one thing stopping me - data protection legislation. In the UK we have this wonderful thing called the Data Protection Act. Which, essentially governs what a company may/may-not do with your data. I'm sure similar legislation must also exist in other countries.Of particular relevance to this "Stealth AJAX" are the following points:
"Personal data must be obtained fairly and lawfully. The data subject should be informed of who the data controller is (the institution); who the data controller’s representative is; the purpose or purposes for which the data are intended to be processed; and to whom the data will be disclosed."
The first stumbling block - you actually are legally obliged to tell the user that you are capturing their data and what you intend to do with it.
"Personal data must be kept accurate and up to date and shall not be kept for longer than is necessary"
As data captured will likely be incomplete then it becomes difficult to prove that it is kept up to date. The fact that a company has a copy of this data also goes a long way towards saying it has been kept longer than necessary.From the user's point of view, they also have the right to prevent data processing for the purposes of direct marketing, which begs the question - what is the point of capturing incomplete application data in the first place.All of these points make it too big of a risk for most companies to even contemplate this kind of data capture. That of course leaves individuals, but look at it this way... if you add a bit of AJAX to your site to steal a user's data (perhaps password phishing?) then what value do you get out of it? You will be discovered sooner rather than later, and lets face it - people are a lot more alert to this kind of thing, so your probably not going to capture anything of value.There are situations, such as offering Auto-Save functionality where this kind of thing is really useful - but lets save it til the user has actually signed up to your application/service!
26 Feb 2006

Torn Between Delphi

Okay, so have to really post this. My housemate, friend from work and random are in a band and have just recorded their first album. Band's name is Torn Between Delphi and you can find their songs here. There not bad, not bangy at all!
21 Feb 2006

Future of Web Apps Podcasts

Just a quick note to sat that the podcasts from this months Future of Web Apps summit are now online over at Carson Workshops. Hopefully see a few of you at the Rails Workshop at the end of March!
19 Feb 2006

Firefox 2.0

I found this on the Web earlier, and though I don't want to get in the habit of posting useless crap, I just couldn't resist! Sooo cute!UPDATE: Apparently it is a Red Panda. I want one!
17 Feb 2006

Functional Art

Whilst I was enjoying Sushi yesterday happened to come across some interesting urinal design... either that or a cleaner found a nasty surprise waiting in their bucket this morning!Its great to see how even the most mundane things can be turned into cool art. The sink was rather nifty too - just a sheet of glass, totally flat and angled towards the wall.
16 Feb 2006

Google Talk Security Flaw?

Something I have just noticed, potentially a large security flaw with Google Talk, following its recent integration with GMail...I come in from lovely Sushi and find messages in my GMail Talk from contacts not on my contact list, and lots of new contacts on my contact list. Obviously I'm a tad confused - I dont have this many friends!Turns out that my housemate logged onto GTalk from the client (not GMail) while I was away. Although she logged out of the client, GMail still assumed I was logged in under her ID, providing me with access to all her contacts.Obviously a bit of a security flaw if you have a shared computer with both a Gmail account and GTalk client. I had noticed that GTalk did allow login from more than one location, and now I'm definately wondering about the logic behind this. Can anyone out there re-assure me?
10 Feb 2006

GMail Cooks Your Spam!

I noticed this earlier, you can now get spam cooking tips and recipies direct from Google Mail! Take a look at the Web clips displayed in your Spam folder. Its these nice touches which make me love Google!
8 Feb 2006

The Future of Web Apps

Today a group of us from work will be attending the Future of Web Apps Summit, organized by the nice folk at Carson Workshops. Throughout the day I'll be doing my best to bring you updates and reactions!
8 Feb 2006

First Impressions

Well, we have all made it to Kensington Town Hall without getting split up, seperated or otherwise lost. Oddly I have also just realised that I have been here before, for the 1999 World of Amiga Show. A very unexpected blast from the past - I wonder if Pedro will be here?First impressions are really that 800 Web developers really are a lot of people. We find a seat near the front, passing a group of people who seem to be having a "Who has the biggest laptop screen?" competition - as much as I would love to have a MacBook, I would much prefer a 13" Model!The lights dim, we take our seats for the first speaker...
8 Feb 2006

Joshua Schachter: Del.icio.us - Things we've learned

First up is Josh, creator of Del.icio.us, talking about his experience of building del.icio.us and what him and his team have learned.Josh talks about the evolution of del.icio.us from a simple text file, to a one-user database, to what it is today. Interestingly tagging came about simply becuase after a while, it became habit to describe bookmarks as single words. This is definately an example of a Web app which fills a gap - in this case, a better way to store your bookmarks. This seems to be the key to developing a successful Web app - make something which is useful to yourself. This gives you a bit of passion and motivation to make some progress.That bit certainly rings home, at work its normal to develop a Web application over a several month period. A lot of the actual work is simply reusing code without adding much to it. Contrast that to when I code in my spare time, I am a lot more motivated in this because I'm producing something which I will use, and have a lot more development freedom to boot.One bit of advice: release your goods early - try and avoid having closed beta's. This way you build up a user base while you are developing.API'sThese days an API is important, however the API you provide can make or break your application. The likes of SOAP and CORBA add complexty, both to you and those developing on your API so it is worth investigating other options.URL'sA URL should be simple, or at least not expose the back-end of your framework. So for example a URL should never contain a database id of a page/item. Not only does this look ugly, but it also is easy to manipulate, posing a security risk as people can scrape your content.FeaturesThe features you provide influence the behaviour of users and the uses of your Web app.Also, you should not reinvent the wheel. by coding features that are available in other places. A good example of this is private messaging between users - this is done far better over existing IM/E-mail channels.RSSShould be everywhere, but be sure to optimize it.SpammersSpammers come hand in hand with most popular social systems. One technique is not to provide spammers with any feedback/errors once you are onto them, otherwise they will change their approach.TagsTags are a UI element, aiding user recall and providing some kind of state. They are also used as a discovery mechanism for new content. They are not a means of data distribution.Some users will want to store additional metadata in addtion to tags, others will want to keep things vague.Although you could offer a user auto-tag choosing, it doesn't really help them as you are pushing your choice onto the user - its okay to make them think about it. Similarly, dropdown's of 'official' tags should be avoided.User MotivationThe user is selfish. As an application developer you need to think about what payoff you are offering. Financial incentives to the user are dangerous - once you introduce money into the equation then everything else becomes less important.Ideally you want your app to make the user wanting to bring in more users - breed evangalism! This can also reduce the amount of marketing which you will need to undertake.MeasurementYou should monitor your Web app and measure user behavior. Also measure how the system is performing. Collect numbers for everything!TestingUser Acceptance Testing is very important. It allows you to see if your system matches user expectations. A good way of doing this is User Labs - have the development team behind a one-way mirror while they watch a user play with the application.When testing, don't give the user any instructions or tasks to complete, just observe their natural interaction with the system.LanguageSpeak the user's language! Most of the world uses Internet Explorer, which refers to "favourites", if you start talking about "bookmarks" then people get confused.User RegistrationYou should always let users see/use your site before requiring registration. Perhaps even consider an anonymous/unregistered user account or AJAX lazy registration methods.Registration istelf should be short and sweet, returning the user to the page they were on once completed.A "take your ball and go home" option, allowing a user to delete their account and data, generates trust. Del.icio.us allows users to purge all their data, and the lack of transaction logging in the database means that this is undercoverable, preserving privacy.MarketingZero dollars were spent marketing del.icio.us. User evangalism played a large part.Be aware of communication streams and invade them! If you can spread the word via. email then great, but avoid becoming a spammer. RSS is an emerging communication stream, enable a RSS reader to become a client application for your service. Also consider how desktop apps can consumer your service.CommunitiesDon't think of your system as a community unless that is its purpose, it is far better to develop a system and then see how communities use it. From there you can enable your system to better serve communities if required.

Chris Korhonen's Posterous

I am a British-born UX designer currently based in New York City, with over 10–years experience developing for the web.

I spent 5 years working at American Express, developing their online services and touching many areas including accessibility, usability, search engine optimization, web strategy, content personalization and social media.

Currently I working for Animoto, an exciting start-up whose product is a cutting-edge, automated, video creation platform.

On the technical side, I have lots of hands on experience building with HTML, CSS, JavaScript, ActionScript, Ruby and Java. Recently I authored a book on using APIs to create mashups using Adobe Flex and AIR.