So Motorola bought 50% of UIQ from Sony Ericsson. I guess all we can say for certain is that Motorola is showing its dedication to the platform.
And of course, some people start speculating about a possible move of UIQ from Symbian to some other OS (like Linux). It's interesting how these speculations keep popping up again and again, even though the whole thing wouldn't just be (almost) impossible, but also completely pointless. You couldn't port UIQ or S60 to run on another OS, because Symbian is quite different from all other systems, and the UIQ and S60 code is filled with excentric Symbian idioms. Sure, you could spend a few years reimplementing the Symbian API:s on top of some other system, but the most important reason for moving away from Symbian would be to get rid of those API:s. The main problem with using Symbian isn't licensing fees, but that developing for it is such a nightmare.
Tuesday, October 16, 2007
Friday, October 5, 2007
Operators and applications
"Operators tend to have a very specific vision of the image they want to project through the third-party applications they sell, if they choose to sell applications at all. Most operators are still in a content 'stone age', offering mostly ring tones and games." (Here's a link to the interesting article.)
Yes, well, I think part of the problem is that it's a much more complex situation with applications than with games or ringtones. Games and ringtones are obvious customization items: we all have different tastes, so we want different ringtones. It's not a deficiency in the device that it's lacking the perfect ringtone for me, or a game to keep me occupied while I'm on the bus. Applications, however, is a different story. If you have to buy Handy Weather for your phone, the lack of a built-in weather app is quite obvious. It's even more obvious if the application you want to sell is a better replacement for an embedded app. Why wasn't the better app already installed when I bought my phone? Right, because the operator is only there to make money. It's all about appearance.
On a more technical level, applications feel more scary. A ringtone doesn't have any functionality, it's just a sound file. A game just draws stuff to the screen. At least that's what you'd believe if you're not an engineer. An application extends and alters the phone's behaviour. Who knows what it might do? Who knows how the users might react to these changes?
And then there's the infrastructure. That an application is Symbian Signed and can be installed without warnings on a phone doesn't mean that it's actually been tested on it. It's been tested on a compatible phone, but how compatible is compatible? How much testing does our operator have to do to feel confident enough about an app to start pushing it to their users?
Yes, well, I think part of the problem is that it's a much more complex situation with applications than with games or ringtones. Games and ringtones are obvious customization items: we all have different tastes, so we want different ringtones. It's not a deficiency in the device that it's lacking the perfect ringtone for me, or a game to keep me occupied while I'm on the bus. Applications, however, is a different story. If you have to buy Handy Weather for your phone, the lack of a built-in weather app is quite obvious. It's even more obvious if the application you want to sell is a better replacement for an embedded app. Why wasn't the better app already installed when I bought my phone? Right, because the operator is only there to make money. It's all about appearance.
On a more technical level, applications feel more scary. A ringtone doesn't have any functionality, it's just a sound file. A game just draws stuff to the screen. At least that's what you'd believe if you're not an engineer. An application extends and alters the phone's behaviour. Who knows what it might do? Who knows how the users might react to these changes?
And then there's the infrastructure. That an application is Symbian Signed and can be installed without warnings on a phone doesn't mean that it's actually been tested on it. It's been tested on a compatible phone, but how compatible is compatible? How much testing does our operator have to do to feel confident enough about an app to start pushing it to their users?
Monday, September 24, 2007
Bugs and user errors
Some time ago someone who shall not be named blogged about a user error. In a certain popular IDE for a certain world-leading smartphone OS, there are two ways to shut down the emulator: you can do it from the IDE or by clicking the little red cross in the upper right corner of the emulator window. The above mentioned blogger had experienced problems when he used the little red cross: it'd take up to five minutes for the emulator to shut down properly. After contacting technical support, he was informed that a bug in the host operating system caused this, and that he should shut down the emulator from the IDE instead. He considered his previous way of doing it a user error.
Now, I know that programmers aren't always wizards of usability, but considering that a user error is like... stupid. I posted a comment where I compared it with a case that I considered to be analogous: let's say you have a document viewer, and you can scroll up and down either by using the cursor keys or by dragging a scrollbar, but if you use the keyboard, the app will crash at random now and then. Would you consider it a user error to use the keyboard to scroll in this case? Probably not. It's a bug.
The comments on that blog are checked by the blogger before they're actually displayed, and it seems my comment wasn't okay, which is why I'm writing about it here instead.
Oh, and by the way, do you know how sweet it is to do some Linux development after being stuck with Symbian for the last couple of years? Sweet as Arabian sweets, I tell ya!
Now, I know that programmers aren't always wizards of usability, but considering that a user error is like... stupid. I posted a comment where I compared it with a case that I considered to be analogous: let's say you have a document viewer, and you can scroll up and down either by using the cursor keys or by dragging a scrollbar, but if you use the keyboard, the app will crash at random now and then. Would you consider it a user error to use the keyboard to scroll in this case? Probably not. It's a bug.
The comments on that blog are checked by the blogger before they're actually displayed, and it seems my comment wasn't okay, which is why I'm writing about it here instead.
Oh, and by the way, do you know how sweet it is to do some Linux development after being stuck with Symbian for the last couple of years? Sweet as Arabian sweets, I tell ya!
Monday, September 10, 2007
Bad language
This is old, but I'm in a bit of a ranting mood, for some reason... I read some comment on a blog about the C language, and how it sucks for several reasons. Of course it sucks if you want a language with garbage collection and bounds-checking. If you want that you use some other language. If you want a portable assembler, you use C or C++. Or something similar, if you're feeling excentric. It's pretty simple: C sucks if you want Python. Python sucks if you want Java. Java sucks if you want Prolog. Prolog sucks if you want Intercal.
Thursday, August 23, 2007
Nokia 6120 Classic
I got myself a new phone, a Nokia 6120 Classic. It seems to be a really nice phone. It's small (for a smartphone), it's cheap (not that I paid for mine, but anyway), it's 3G and it's fast (for an S60 device). It has a solid feel to it too, not the typical plastic feel that so many phones have, including most of Nokia's other S60 devices. It also doesn't look horrible, like some other phones. Too bad it doesn't come in spectacular colours (only black and white), because I would have loved a yellow one.
As a bonus, it comes with some code written by yours truly: the embedded game Marble Cannon runs on mophun, with my Symbian integration. It's a pretty nice game (haven't tried it before, Johan started coding it about the same time I quit my job at Synergenix), but maybe a bit too easy.
As a bonus, it comes with some code written by yours truly: the embedded game Marble Cannon runs on mophun, with my Symbian integration. It's a pretty nice game (haven't tried it before, Johan started coding it about the same time I quit my job at Synergenix), but maybe a bit too easy.
Sunday, August 5, 2007
Open platforms
Some people don't think you should call the iPhone a smartphone, as it's not an open platform, while most people seem to agree that phones running SymbianOS are indeed smartphones. Well, at last the S60 and UIQ ones. The accepted distinction between open and non-open platforms seems to be that open platforms let you install third party native code. However, seeing as most open systems are more or less closed, as they only give third party developers access to a select subset of the system's API:s, it might be more useful to think of open vs. closed systems as a scale that ranges from completely closed to completely open.
A PC running an open source OS (or the Neo 1973 smartphone) is about as open a platform as you'll find, while a wristwatch is a completely closed system. Between these you have systems like the iPhone, that lets you install widgets, with little access to system functions, feature phones that let you install Java midlets and typical smartphones, that let you install native code apps, but don't give you access to the full set of system API:s, and won't let you replace system components.
The iPhone is less open than a typical feature phone, but it's also more "smart" than those, as it's running a real OS, just like smartphones. This just shows that categories like feature phones and smartphones are too simplistic. It was a good idea to use these categories 5 years ago, when open phones was something new and exciting.
A PC running an open source OS (or the Neo 1973 smartphone) is about as open a platform as you'll find, while a wristwatch is a completely closed system. Between these you have systems like the iPhone, that lets you install widgets, with little access to system functions, feature phones that let you install Java midlets and typical smartphones, that let you install native code apps, but don't give you access to the full set of system API:s, and won't let you replace system components.
The iPhone is less open than a typical feature phone, but it's also more "smart" than those, as it's running a real OS, just like smartphones. This just shows that categories like feature phones and smartphones are too simplistic. It was a good idea to use these categories 5 years ago, when open phones was something new and exciting.
Wednesday, August 1, 2007
Web 2.0 vs. open source
I read this article over at AllAboutSymbian some time ago. It seems 3 want their users to create their new portal, web 2.0-stylee. In a corporate context, this might sound like a superb idea: someone else does the work, you cash in. It's like with open source around 2000: there was a wide-spread perception that you could just upload your code to sourceforge, and thousands of nerds around the world would start doing the work for you, Linux-style, or Mozilla-style. However, those nerds need some sort of incentive. It just won't work for any project. It works exceptionally well for cool projects like the Linux kernel, but might not work as well for something completely uncool, like an office suite.
Web sites with user contributed content work great if the users feel that it's a good service, ie. if it's fun or useful. Adding links to mobile sites to 3's mobile portal probably isn't much fun. I know I couldn't be bothered.
Web sites with user contributed content work great if the users feel that it's a good service, ie. if it's fun or useful. Adding links to mobile sites to 3's mobile portal probably isn't much fun. I know I couldn't be bothered.
Subscribe to:
Posts (Atom)