Comments for Usability Bites

Comment on More Smooth Sounds by Kuba Ober

Kuba Ober — Fri, 21 Jan 2011 16:47:04 +0000

I’ve seen this idea in action in a public transit system somewhere in Japan. Each station had a particular tune assigned to it. The tune was played over the train car PA system just before rolling into the station. On a crowded train, where fellow passengers may be obscuring both outside view *and* the onboard displays, this was a great usability booster.

Comment on More Smooth Sounds by PatoId

PatoId — Tue, 23 Jun 2009 01:04:17 +0000

Probably the people who made the wrong choices on how sounds should default were just too bothered by noise. I once worked on a device that had a tamper switch and emited an alarm when that tamper switch had been open. It was a very important function so we had to test it a lot of time and on several units, the amount of noise was amazing. The week we ran those tests for the first time I started dreaming beeps, I also started using my cell phone in only vibration mode as any high pitch noise would cause a headache. Then I discovered I could just put a piece of tape on top of each buzzer and the noise would be reduced to a point where it didn't bother me, too late

Comment on (Code) Size isn’t everything… by Niall Murphy

Niall Murphy — Wed, 13 May 2009 05:10:00 +0000

I agree with Nigel that it would be handy to have a guide to which are the more expensive (in terms of code size, and maybe speed) objects and which are less resource hungry.I think any such guide would be fairly rough because the cost of many objects varies with use. A BitmapButton’s size probably depends more on the size of the bitmap than it does on the code of BitmapButton itself. Similarly fonts (especially Kanji) can take up big chunks of ROM, and that is beyond the control of the GUI library.If vendors are going to start categorizing their objects, I often wish that would also document which ones use dynamic memory and which do not. Some projects try to apply a coding standard rule that no dynamic memory management is allowed after startup, and this is sometimes possible with a GUI toolkit, as long as you avoid certain objects.

Comment on (Code) Size isn’t everything… by Nigel Jones

Nigel Jones — Wed, 13 May 2009 00:21:00 +0000

I'm a big proponent of using a third party graphics package – in part because I think companies should concentrate on their core technologies. Having said that, one of the things I'd like to see documented a lot more in graphics libraries is both the absolute and marginal costs of each type of control. In other words, what will it cost me to use widget X if I'm already using widgets C, H & P? I can of course run experiments – but I'd rather have this information up front so that I can plan my UI. As well as helping minimize the size of the object code, this also allows me minimize the potential number of bugs (using the simplistic assumption that bugs are uniformly distributed throughout the code).

Comment on Three Most Painful GUI Challenges by Paul N. Leroux

Paul N. Leroux — Fri, 06 Mar 2009 17:00:00 +0000

Re Keep it simple. I always like to use the Google home page as an example. It’s the most widely used user interface in the world and it serves as the front-end to an unbelievable variety of features, applications, and services. And yet, it is 90% white space — just a text field and a few links. Which is exactly why everyone feels comfortable using it. Because they can!

Comment on Three Most Painful GUI Challenges by Nigel Jones

Nigel Jones — Sun, 08 Feb 2009 16:44:00 +0000

I agree completely with your thoughts on too many features being crammed into products. I’ve noticed a couple of things that go along with this.1. The developer that resists adding features can easily get the reputation of being ‘uncooperative’ instead of what they really are – which is protective of the product.2. A lack of understanding that added features tend to have a very high bug rate. I think this comes about because they are tacked on, rather than designed in. I’ve found this to be a very persuasive argument when it comes to not doing something.

Comment on Lying to the User: An Ounce of Inaccuracy is Worth a Pound of Explanation by Charlie

Charlie — Mon, 11 Feb 2008 11:37:00 +0000

I too have designed several digital pressure indicators and have resorted to using a “zero dead band capture” at marketing’s insistence. As an engineer, I was perfectly happy to see the instrument displaying 0.001. That way I knew it was working properly and not gone dead. I usually restrict my capture range to +/- 2 displayable counts although I did increase this on some very low range sensors. I remember a similar situation when I had designed a portable field calibrator with 5 digit resolution. It had simultaneous input and output functions so the simple way to test or demo the unit was to jumper the input to the output. My boss was bring some (non-engineering) guests through the lab so I set the unit to the 1V range (its best) and keyed in 1. The output went to 1.00000 and the input showed 0.99999. The guest looked at it, sniffed, and said “not working too well I see!”. Oh well, how does one type a sigh.

Comment on Tradeoff: Easy on the Eye or Easy to Use by Charlie

Charlie — Mon, 11 Feb 2008 11:28:00 +0000

I agree with your thought about “pretty” versus “functional” but here in the US there is a standard for plumbing. Cold on the right, hot on the left.