Da Gampa's Code

Personal weblog of Jakub Hampl who is an AI & Psychology student at Edinburgh University.

Ask me whatever you want. I'll reply to whatever I want.

UX considerations of using Flash

There has been a lot of discusion around the web surrounding the use of Flash on websites. The discusion was geared mainly about the availability of Flash on some platforms and it’s general slowness on others.

That is not my point today.

What I do want to talk about is the value of Flash to the most regular user - the one who can run it reasonably fast and has it installed on his computer.

I’ll start with the benefits. Less work for the developer in bringing rich capabilities to inferior browsers. If you still use Internet Explorer I think you probably wish Flash was used a lot more. Especially today when developers are getting these dangerous ideas about things like graceful degradation and “your experience is only as good as is your browser”. Also if the developer can spend less time optimizing and testing on every browser he will have more time to polish other aspects of the app. Next I’ll mention the obvious: there are things that cannot be done without a plugin - you might as well use flash for them (full screen video and progress with uploading being the most prominent examples at time of writing).

Now the negatives: although Flash is improving in this area, I argue that it has small and hard to spot usability issues. These can be often circumvented with using a combination of html and Flash (but thus loosing some of the benefits). First imagine a login form in Flash. Now if you try to use 1Password or any other password manager to store and remember that password for you you will be disappointed. They can’t detect the form to be a login form. Neither does the browser’s native password manager kick in. This forces you to set a password that is easy to remember and thus making it much less safe.

Also, almost shamefully so, somehow Flash does not support undo when editing text. Again this is not a huge problem in most cases (since Flash is usually not used as a text-editing environment) but it is another dent in the UX facade that can irk your user.

However for me the most irking thing about a lot of Flash apps is scrolling. I’m using a MacBook and I’ve grown so used to the comforting double finger scroll that I almost forget how to use a scrollbar. That is until I use a Flash app. Somehow Flash scroll views don’t seem to support mouse wheels out of the box. This issue is somehow overridable but rarely does this happen.

There are other issues that I might have missed; the point is however when deciding what technology to use don’t forget to consider these smaller however important points, especially when designing software that people will need to use on a frequent basis (if you’re doing a casual game then Flash is quite probably perfect for you).

#ux #flash 

This is an amazing user interface solution for effective multitouch on the desktop.

It also solves some problems with organizing your desktop in a reasonable manner. This is a problem I have been thinking about and the proposed solution seems interesting. (If this is your problem, checkout this app.)

Hint: The second part of the video is much more interesting then the first.

#ux 

Call Centers and UX

I was trying to get internet into my new flat. I decided to call an ISP.

A phone bot answers the call. No surprise here. This is the usual procedure and it’s hard to conceive of a better way to do this.

I get to the part where you’re supposed to get to a human operator. Now we get to several different options.

  1. The operator answers right away. This is great and we’re done.
  2. Horrible music starts playing. Then you wait. And you wait. And then you wait some more. Now this sucks horribly. The music is always terrible and you just plain don’t know how long are you going to be waiting. This is especially terrible if you don’t know that you’re calling the right number to solve your problem. Also consider that you may be paying for this exercise in patience.
  3. The PhoneBot gives you a estimate and then 2. This is a lot better then B because at least you can hang up if it’s hopeless.

Now out of the alternatives 1 is obviously the best. However I understand that this may be difficult to achieve due to resource constraints.

This is my proposal: When a person calls, make an estimate for his waiting time. If it is short (less then 2 minutes) tell him so and let him wait. If it’s longer apologize, tell him the estimate and save his number. Tell him that you’ll call him in the estimated time. If the user wants to wait, let him (there may be situations were this is more convenient). Whenever an operator is ready, call the user. If he doesn’t pick up, send him a text message explaining the situation.

Does that sound like a reasonable way for an interaction?

#ux 

I’m not sure how new this feature is, but I just heard of it recently. If you do almost any action on OS X that involves animation (I suppose powered by Core Animation, but I’m not sure) holding down the Shift key will slow the animation down.

Tip: try it out with editing dashboard.

via @phelement

#ux