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.
Thursday, May 24, 2007
A real trojan for S60 phones
"Finally" there's a piece of malware for Symbian phones that actually does damage. Of course, there's not much risk of getting infected by it: it's a simple trojan, uploaded to a file sharing site, posing as a utility. Once installed, it'll send SMS messages to a premium rate number, effectively adding about $7 to your phone bill. The descriptions of it seem to suggest that it only sends one SMS per infected phone, which makes me think it's more of a proof of concept implementation. The program runs on S60 1st and 2nd edition phones.
There shouldn't be any problems porting this thing to 3rd edition, which is interesting, considering how much pain Symbian and partners are willing to inflict on developers for the sake of security. This app doesn't need any restricted privileges and would not need to be Symbian Signed. Sure, the user gets an extra warning at install time, but people who install 3rd party software on their Symbian 9 phones are used to that, and will just press OK. Autostarting the app might be a problem, but that shouldn't be an issue: the user is obviously going to start the app after installing it, at which point it can start sending its premium rate messages. A clever coder would of course spawn a background process that keeps sending new messages continuously.
But well, writing software that does damage after the user has manually installed it is never going to be difficult. Writing code that could install itself without user interaction would be a real challenge.
There shouldn't be any problems porting this thing to 3rd edition, which is interesting, considering how much pain Symbian and partners are willing to inflict on developers for the sake of security. This app doesn't need any restricted privileges and would not need to be Symbian Signed. Sure, the user gets an extra warning at install time, but people who install 3rd party software on their Symbian 9 phones are used to that, and will just press OK. Autostarting the app might be a problem, but that shouldn't be an issue: the user is obviously going to start the app after installing it, at which point it can start sending its premium rate messages. A clever coder would of course spawn a background process that keeps sending new messages continuously.
But well, writing software that does damage after the user has manually installed it is never going to be difficult. Writing code that could install itself without user interaction would be a real challenge.
Saturday, May 19, 2007
The sun
It seems I missed this while I was busy getting jetlagged. Sun are porting their recently acquired SavaJe platform to run on Linux, and building a complete phone platform to be licensed to phone manufacturers. They don't have any licensees yet, and it'll be interesting to see if they'll manage to get anywhere in a field of business where Microsoft have failed quite spectacularly. I guess Sun have a greater chance of getting this platform out there than SavaJe did, with their resources, but at the same time, it's obvious that you can't just throw money at something and expect it to be a hit.
The linked article says that the software will only be distributed in binary form, to keep compatibility between handsets. I'm not sure if phone manufacturers and operators will be too happy about that. With a well designed system, there might be enough hooks in there to make differentiation possible, but there's only so much you can do without the source code. I think one problem with Windows Mobile is that it's so heavily branded as a product in itself. Handset manufacturers and operators want it to look like the whole package is their own product. This might turn into a problem for Sun, and they might have to reconsider the binary distribution model. Compatibility is nice, but I think this is mostly a concern for them, not for their customers or the end users. This is not the desktop or server market, end users aren't interested in compatibility, most of them don't even know that they can install software on their phones.
Again, it's nice to see some new products in this field. We already know that it's a very tough market: S60 and UIQ still don't have many licensees outside of Nokia and Sony/Ericsson. What makes Sun think that they'll succeed? Using a whole new system is a very big decision, as it's a huge effort to get to understand it, train people to work with it etc.
(And finally, the linked article is full of these naive iPhone references we've seen in almost every phone related article in the press since it was announced. Please, stop it already, you're just making yourself look clueless.)
The linked article says that the software will only be distributed in binary form, to keep compatibility between handsets. I'm not sure if phone manufacturers and operators will be too happy about that. With a well designed system, there might be enough hooks in there to make differentiation possible, but there's only so much you can do without the source code. I think one problem with Windows Mobile is that it's so heavily branded as a product in itself. Handset manufacturers and operators want it to look like the whole package is their own product. This might turn into a problem for Sun, and they might have to reconsider the binary distribution model. Compatibility is nice, but I think this is mostly a concern for them, not for their customers or the end users. This is not the desktop or server market, end users aren't interested in compatibility, most of them don't even know that they can install software on their phones.
Again, it's nice to see some new products in this field. We already know that it's a very tough market: S60 and UIQ still don't have many licensees outside of Nokia and Sony/Ericsson. What makes Sun think that they'll succeed? Using a whole new system is a very big decision, as it's a huge effort to get to understand it, train people to work with it etc.
(And finally, the linked article is full of these naive iPhone references we've seen in almost every phone related article in the press since it was announced. Please, stop it already, you're just making yourself look clueless.)
Friday, May 18, 2007
Big in Japan
A couple of days ago I got home from Japan. From a mobile perspective, Japan is very interesting. It's about as different from the rest of the world as USA. They just do everything their own way. I'm not going to try to analyze that stuff, though, as I believe that there are others who can do that much better than me. I didn't exactly spend much time studying mobile phone usage when I was there, instead I concentrated on sightseeing and drinking beer, so I'll just report on some observations I made:
One thing that I've talked about before is how colourful and beautiful the phones are. The Japanese also seem to use them a lot. And it's not like they mainly use them for placing calls. I'm not exactly sure what they use them for, but my brother's wife told me that they don't use SMS much in Japan. Instead they use email, but not with their regular email account, but with another address that's specific to the phone. So it's the same as SMS, except that there's no arbitrary limit on the length of messages. I guess the disadvantage is that you actually have to know someone's email address to be able to send an email, while with SMS you just need to know the phone number.
Then there's all the whimsical stuff about the straps, emoticons etc., but I'm not going to go into that, but it fits in well with Japanes pop culture, I guess.
One thing that I've talked about before is how colourful and beautiful the phones are. The Japanese also seem to use them a lot. And it's not like they mainly use them for placing calls. I'm not exactly sure what they use them for, but my brother's wife told me that they don't use SMS much in Japan. Instead they use email, but not with their regular email account, but with another address that's specific to the phone. So it's the same as SMS, except that there's no arbitrary limit on the length of messages. I guess the disadvantage is that you actually have to know someone's email address to be able to send an email, while with SMS you just need to know the phone number.
Then there's all the whimsical stuff about the straps, emoticons etc., but I'm not going to go into that, but it fits in well with Japanes pop culture, I guess.
Subscribe to:
Posts (Atom)