It's interesting how hard it is to design user interfaces. Even if you have usability designers involved in the process, even if you go through lots of testing, user interfaces always seem to excel at annoying the users. I've talked before about confirmation dialogs, and well, I just can't stop being annoyed by them, so here we go again...
Today I started writing an SMS, then realized that I should call this person instead, so after writing 2 or 3 letters, I pressed Cancel. Of course the phone has to pop up a dialog, asking me if I'd like to save what I've written so far as a draft. No, thank you, that wouldn't be of much help, actually it wouldn't make sense at all. But the code in the messaging application has registered input, and so has to pop up that dialog. Now, how hard would it have been to introduce some arbitrary limit on the minimum number of letters typed, before popping up that dialog if Cancel is pressed? A few lines of code should do it.
Of course, doing this might seem a bit dangerous. Maybe the user is counting on getting that popup when pressing Cancel. Maybe some users like to save lots of 2-3 letter drafts, to reuse later. Don't mind the fact that opening it would take longer than re-typing those 2 or 3 letters. Well, I don't think it matters. More users are likely to be annoyed by the confirmation dialog than by losing a few words of text.
Or, well, what do I know?
Friday, June 29, 2007
Thursday, June 28, 2007
The final chapter. And the first one.
Sony/Ericsson announced that they've now shipped the final firmware for the P990, the M600 and the W950. It seems there are still quite a lot of issues, and parts of the smartphone fanatics crowd are furious. I can understand them, because they've paid for expensive devices, which are now pretty much obsolete.
But in a way, isn't it better to move on and forget about this whole disaster? Sometimes you buy things that aren't as good as you expected. Sony/Ericsson probably made more money from these phones than they're losing from bad publicity. And I'm sure they've learnt their lesson. Don't try to integrate a major new OS version along with several new networking technologies in one device. It's too complicated. Software engineering really isn't that advanced. There's a limit to how much complexity it can handle.
And tomorrow the iPhone will start selling in the USA. Initial reviews seem to indicate that it lives up to the hype, but we'll see how well it's holding up in the real world. It seems Apple did the right thing, despite the fact that this is their first phone. They chose not to include 3g or MMS. You can't even use the camera to record videos. If they'd tried to add as much nerd-magnet technology as in the N95, they might have failed spectacularly. With that much hype, lots of people were probably hoping that it would.
But in a way, isn't it better to move on and forget about this whole disaster? Sometimes you buy things that aren't as good as you expected. Sony/Ericsson probably made more money from these phones than they're losing from bad publicity. And I'm sure they've learnt their lesson. Don't try to integrate a major new OS version along with several new networking technologies in one device. It's too complicated. Software engineering really isn't that advanced. There's a limit to how much complexity it can handle.
And tomorrow the iPhone will start selling in the USA. Initial reviews seem to indicate that it lives up to the hype, but we'll see how well it's holding up in the real world. It seems Apple did the right thing, despite the fact that this is their first phone. They chose not to include 3g or MMS. You can't even use the camera to record videos. If they'd tried to add as much nerd-magnet technology as in the N95, they might have failed spectacularly. With that much hype, lots of people were probably hoping that it would.
Friday, June 22, 2007
The Symbian OS Architecture Sourcebook by Ben Morris
As a Symbian developer, you're locked out from most of the system-level information, which is why it's a good thing that books like this one, Symbian OS Internals and Symbian OS Platform Security are published. Just like those other books, this one contains some very good information, and is a very frustrating read because of all the omissions and/or the weird structure.
The author of this book is trying to do two things with this book: to provide a description of the high-level design of the OS and to tell the history of the development of it. This sounds manageble, but it leads to a very fragmented book. The most interesting stuff is contained in the first part, which is mostly historical. Here we get explanations for stuff like descriptors and MMP files (they were borrowed from VMS), and gain an understanding on why Symbian OS is such a weird system (most of the architects just don't seem to know much about computer systems, so they invented everything as they went along).
The second part is a description of the different parts of the system. This one probably isn't meant to be read straight through, and I found myself skipping quite a few pages. This section isn't boring just because of the topic, but mostly, I think, because it's so badly written. Everything is repeated a great number of times, which gives the book a distinctly American feel, although (I believe) the author is British.
The third part consists of case studies, and is more similar to the first part. There's some interesting history here, but much of this stuff is repeated from the first part, and reading it for the second time doesn't exactly make it more interesting.
The reference in the appendix feels quite unnecessary. It's just a listing of components, with some basic facts, such as their names, build file location, which OS releases they're included in and one line descriptions. I don't quite get the point of including this part in the book, in the Internet age. This would have made much more sense in electronic form, where it can be easily searched, and much more information could have been included.
One theme that runs through the whole book is what I'd like to describe as the effects of the Symbian Reality Distortion Field. Steve Jobs might have made it famous, but Symbian Ltd. are without a doubt the masters of creative bending of the truth. Sure, we've heard most of this stuff before, but anyway, here are a few examples: Descriptors, the first thing most developers will mention when ranting about how weird and difficult Symbian is to program for, is described as a gift from god. Active objects are described as the best possible event handling mechanism, despite the headaches it gives developers. I suppose the author hasn't bothered to study alternative solutions, as the only alternative he mentions is the archaic event loop. The praise of the horrible UI framework feels more like an insult than anything else, and claiming that "the system has been optimized to produce fast graphics on low-power devices" is just crazy. Anyone who's tried using the Symbian graphics routines know that that's just not true. The only way to get decent graphics performance out of a Symbian device is to use Direct Screen Access, which bypasses the system's drawing code.
On a more positive note, the description of the system design gives me the impression that a lot of good design decisions have been made on a high level. Unfortunately for the developer, on the API level everything seems to have gone wrong. The explanation for this seems to be that the designers were learning C++ as they were constructing the API:s.
All in all, the first part makes the book worth reading, and the other parts provide some additional insights. Again, it's a book that gives you information that you can't find anywhere else, unless you're a Symbian (or partner) employee, and for that reason it's worth reading. However, the evangelism is quite offensive, so it's not an easy read if you've just eaten.
The author of this book is trying to do two things with this book: to provide a description of the high-level design of the OS and to tell the history of the development of it. This sounds manageble, but it leads to a very fragmented book. The most interesting stuff is contained in the first part, which is mostly historical. Here we get explanations for stuff like descriptors and MMP files (they were borrowed from VMS), and gain an understanding on why Symbian OS is such a weird system (most of the architects just don't seem to know much about computer systems, so they invented everything as they went along).
The second part is a description of the different parts of the system. This one probably isn't meant to be read straight through, and I found myself skipping quite a few pages. This section isn't boring just because of the topic, but mostly, I think, because it's so badly written. Everything is repeated a great number of times, which gives the book a distinctly American feel, although (I believe) the author is British.
The third part consists of case studies, and is more similar to the first part. There's some interesting history here, but much of this stuff is repeated from the first part, and reading it for the second time doesn't exactly make it more interesting.
The reference in the appendix feels quite unnecessary. It's just a listing of components, with some basic facts, such as their names, build file location, which OS releases they're included in and one line descriptions. I don't quite get the point of including this part in the book, in the Internet age. This would have made much more sense in electronic form, where it can be easily searched, and much more information could have been included.
One theme that runs through the whole book is what I'd like to describe as the effects of the Symbian Reality Distortion Field. Steve Jobs might have made it famous, but Symbian Ltd. are without a doubt the masters of creative bending of the truth. Sure, we've heard most of this stuff before, but anyway, here are a few examples: Descriptors, the first thing most developers will mention when ranting about how weird and difficult Symbian is to program for, is described as a gift from god. Active objects are described as the best possible event handling mechanism, despite the headaches it gives developers. I suppose the author hasn't bothered to study alternative solutions, as the only alternative he mentions is the archaic event loop. The praise of the horrible UI framework feels more like an insult than anything else, and claiming that "the system has been optimized to produce fast graphics on low-power devices" is just crazy. Anyone who's tried using the Symbian graphics routines know that that's just not true. The only way to get decent graphics performance out of a Symbian device is to use Direct Screen Access, which bypasses the system's drawing code.
On a more positive note, the description of the system design gives me the impression that a lot of good design decisions have been made on a high level. Unfortunately for the developer, on the API level everything seems to have gone wrong. The explanation for this seems to be that the designers were learning C++ as they were constructing the API:s.
All in all, the first part makes the book worth reading, and the other parts provide some additional insights. Again, it's a book that gives you information that you can't find anywhere else, unless you're a Symbian (or partner) employee, and for that reason it's worth reading. However, the evangelism is quite offensive, so it's not an easy read if you've just eaten.
Tuesday, June 5, 2007
Faking the iOrgasms
I guess you've all seen the iPhone commercials by now. The focus on the cool UI is strong, but it makes me wonder how slick it really is. I don't doubt that the animations will be smooth, but I have my doubts about that photo browser, or more specifically, the speed with which it manages to load a dozen photos from disk. As far as I know, the iPhone uses flash memory, not a hard drive. Flash memory is slow. Noticably slow. As in: you can't load ten photos from it in the time it takes to display a flashy fade effect.
But I guess I shouldn't complain. This is what advertising is about. But it makes me wonder how much else is faked.
But I guess I shouldn't complain. This is what advertising is about. But it makes me wonder how much else is faked.
Subscribe to:
Posts (Atom)