Talk to the Guru: Eco(ding)

[kevin_s2f]

For this Talk to the Guru discussion, Forum Nokia welcomes Antti Rauhala, senior software developer at Futurice, to discuss his work developing the weffset application for Nokia. The application is a great example of the types of applications and services Nokia is looking for in the Eco-Challenge of the Calling All Innovators competition. It provides consumers an easy way to calculate the carbon footprint of their travel, and provides an easy mechanism for them to purchase carbon offsets. Check out a snippet that shows how Antti coded a "share with a friend" feature in the application.

When I asked Antti how long he has been coding, he basically gave me two answers. He has been coding "just about forever". He has been getting paid for coding only a short period of time. Sound familiar?

Antti, welcome to Talk to the Guru.

[antti.rauhala]

For this Talk to the Guru discussion, Forum Nokia welcomes Antti Rauhala, senior software developer at Futurice, to discuss his work developing the weffset application for Nokia. The application is a great example of the types of applications and services Nokia is looking for in the Eco-Challenge of the Calling All Innovators competition. It provides consumers an easy way to calculate the carbon footprint of their travel, and provides an easy mechanism for them to purchase carbon offsets. Check out a snippet that shows how Antti coded a "share with a friend" feature in the application.

When I asked Antti how long he has been coding, he basically gave me two answers. He has been coding "just about forever". He has been getting paid for coding only a short period of time. Sound familiar?

Antti, welcome to Talk to the Guru.

Hi,

First I would like to thank Kevin for inviting me here. I am more than happy to be able to share my experience here and - even more - to listen your thoughts and opinions.

Like said, I have many years experience from Symbian C++, but unlike suggested, I have been paid (even when part-time or trainee) for really long time for the work I have done and enjoyed

I would like to start with short description around weffset project. weffset project from the very beginning - well - it was known as very challenging project. It had extremely tight, almost unrealistic, schedule (localized custom ui+lot of functionality in 2 months) for first release (more for second) and we had not worked on fully localized custom UIs before. In the team, we had me and Katja Konola, working as the project manager/concept owner/graphical designer and doing a great job.

In project, quite lot of the problems raised from drawing UI without S60 standard components, while still needing to support all screen sizes, 60 different languages and the odd N95, Communicator etc. displays with the CBA's going right. Lot of functionality, that is normally provided by the UI framework had to be implemented manually. Layouting supporting right side CBA, left-to-right Arabic, China with high symbols, dozen languages and numerous fonts wasn't that trivia - and well - it all needed to look good. (And of course, there were the problems of background application that could not - in practice - be tested, but which had to work, and payment module, which didn't initially support the diversity of prices, etc. )

Still, with great effort, fixing and fortune we managed to get through a decent first release. With the second release - on the other hand - we had the time we needed to do necessary cleaning and add full localization and missing features in a controlled manner. Eventual result was fully localized custom UI with great UI shine and great quality, and certainly, I am proud for the product we created. Also, I'm grateful for the small part in this effort to help environment.

- Antti

[Sorcery-ltd]

Hi Antti,

First of all, congratulations on a nice looking application!

Next, here's a link in case anyone wants to download it an have a look: http://www.nokia.com/environment/weoffset

I think you've highlighted something really important here:

In project, quite lot of the problems raised from drawing UI without S60 standard components, while still needing to support all screen sizes, 60 different languages and the odd N95, Communicator etc. displays with the CBA's going right. Lot of functionality, that is normally provided by the UI framework had to be implemented manually. Layouting supporting right side CBA, left-to-right Arabic, China with high symbols, dozen languages and numerous fonts wasn't that trivia - and well - it all needed to look good.

The standard S60 components are extremely inflexible and almost impossible to extend. This leads to the need to build your own custom UI almost completely from scratch to do something that doesn't use the standard components exclusively. To me this seems like a lot of work that lots of developers need to repeat unnecessarily. Do you think that there are extra components for layout and custom UI creation that could be added to the platform (and Symbian Foundation code base) to make the task you've just completed a lot easier?

If so, what would you add?

Mark

P.S. I note that your application doesn't follow the standard S60 UI conventions at all, including things like showing the battery status and signal level. Do you think those things are valuable or is it worth being without them in order to make full use of the available screen space?

[antti.rauhala]

Hi Antti,

First of all, congratulations on a nice looking application!

Well, thanks

I think you've highlighted something really important here:

The standard S60 components are extremely inflexible and almost impossible to extend. This leads to the need to build your own custom UI almost completely from scratch to do something that doesn't use the standard components exclusively. To me this seems like a lot of work that lots of developers need to repeat unnecessarily. Do you think that there are extra components for layout and custom UI creation that could be added to the platform (and Symbian Foundation code base) to make the task you've just completed a lot easier?

If so, what would you add?

Definately layouting components would be helpful. Creating a layout to fit every possible phone & locale configuration was really time consuming. To provide nice layouting just providing the following components could be useful...

GeometricList (contains controls in vertical or horizontal order)
EmptySpace with weight (empty dynamic space, which reduces automatically, when space is needed)
Padding with weights (empty dynamic space around single component)
Scroll view (contains limited view to a much bigger control)

The idea would be, that you could create list including not only the actual content but also the empty spaces that ought to be put between list items. When list were to be stretched (e.g. according to screen size), what space would be left from the 'actual' list items (texts, pictures, etc.), the remaining would be divided among the 'empty spaces'. If we have 5 empty spaces and after 'real items' 150 pixel is left, each empty space could take e.g. 30 pixels of height. If we had only 15 pixels, then each space item would have 3 pixels. If there simply were not enought space, a scroll could activate(, or font size could be reduced). This is quite basic functionality available in most UI SDKs (starting from Java), yet it is lacking in S60, where dynamic layouting would be needed most. When creating Custom UI for the numerous screens, locales and soft key locations, the UI really needs to 'stretch'.

TBH. I didn't use S60 controls for providing the UI. Instead I did draw the controls directly on the screen, considered as the best way by my collegues (how are you going create custom UI lists anyway?). While it is known as 'the easy way' (that is horribly time consuming kind of 'easy') (and with schedule we had there really were no options), it is destined to lead to problems. E.g. let's consider S60 5.0. I can promise: weffset won't work with devices like Tube, and so won't most of Custom UI applications.

P.S. I note that your application doesn't follow the standard S60 UI conventions at all, including things like showing the battery status and signal level. Do you think those things are valuable or is it worth being without them in order to make full use of the available screen space?

Unfortunately this is the case. There are also other issues (fortunately small) that are are mostly unvisible. Partly the 'compromises' were caused by the time, it takes certain time before proper graphics and functionality gets to be done and finetuned for the UI style. And in this sized project, this overhead is quite significant.

Partly it was just that there were certain desires expressed towards the software's appearance and behaviour, and battery status and signal level weren't part of that.

- Antti

[kevin_s2f]

First I would like to thank Kevin for inviting me here. I am more than happy to be able to share my experience here and - even more - to listen your thoughts and opinions.

My pleasure. This is going to be an interesting discussion.

It had extremely tight, almost unrealistic, schedule (localized custom ui+lot of functionality in 2 months) for first release (more for second) and we had not worked on fully localized custom UIs before. In the team, we had me and Katja Konola, working as the project manager/concept owner/graphical designer and doing a great job.

It seems much of life runs like that. "If I had only known then..." is sometimes a cry of frustration, sometimes an indication that one has tackled something interesting and learned something useful. So .... if you had known then what you know now, what would you have done differently?

[antti.rauhala]

It seems much of life runs like that. "If I had only known then..." is sometimes a cry of frustration, sometimes an indication that one has tackled something interesting and learned something useful. So .... if you had known then what you know now, what would you have done differently?

In the retrospective it seems, that we got most things right, happy to say. It is anyway never that trivia in the software engineering, but while localized custom uis were bit new for us, we have done this sort of applications before and we knew what we expected.

What I recognized in the great hurry of first release was - well - the problematic nature of hurry. For me it seems that, when facing tight schedules, there is only few places where to save time. I would claim that trying to 'program faster' is a poor idea. This is simply, because most efficient quality assurance occurs, when the software programmer creates the software with care in a controlled manner, having a thoughtful oversight over what he has created or creating. Under hurry, because the human nature, this kind of carefulness suffers first in order to save time, but in reality it provides no real time savings, instead much more of the opposite. While we managed to push a first decent release out in the end, before that wasted lot of time innecessarily in several 'boomerangs' ~ failures from Symbian testing for the little mistakes resulted from hurry. It really seems, that there are really no other efficient ways to save time, but downwards scoping ~ which in the end - should be somewhat obvious.

Another thing learned from the project relates to the localized custom ui tricks. I guess the next similar project could be pushed forward in much less time. Some of the notes are simply that

a) check the formatting in the localization files by using some script or Java code in my case. A small mistake in any of the hundreds localization files will crash the application in instant.

b) Maximum size for single localization string is 512 bytes, because resource compiler limitations. The strings should be put into properiate pieces before sending them to localization, recognizing their tendency to grown. Otherwise you'll end up doing the very same work for 60 languages, instead of just 1.

c) Layouting is problematic. The proper way to do it is by first calculating that how much the text (with amount of wrapped lines solved) and pictures will take space, and then dividing the remaining space for the empty space between and around items. If remaining space is negative, this is the moment to drop the font or scale images down. This may be lifesavior with really tall symbols (like China) combined to 'vertically challenged' displays.

d) Do not touch RWindow directly. I did, I regretted. I tried to use it with background application, but with little success. The basic UI framework services are simply not available like information about screen size, button locations, linewrapping&localization etc. etc. Creation of localized and well-behaving custom ui pop-up from non-Avkon process seems impossible.

e) If you cannot really test something (like with background application, which detects travels from one country to another. Testing would require international travel), then reserve good amount of time, a (mental) microscope and go through whole application sources line by line, validating that every piece of code is well-behaving even considering all special cases. It won't hurt to add systemical comments for each line (e.g. 'ok') to assert safety or remind of special considerations. It worked for me (6 source files, several hundred LOCs)

f) Special cases checklist
1) Birectional languages (Arabic, Hebrew) (use TBidiText). Affects also menu and list layouts (use AknLayoutUtils::LayoutMirrored()).
2) East-asian symbolic languages (China has tallest characters). Note: All fonts will not work.
3) Screen size & soft button location variation and changes (e.g. N95) (use AknLayoutUtils::CbaLocation())
(4) Phone call. When someone is calling, you should display phone symbol )
(5) Battery )
(6) Signal strength )

g.. And so much more. What can I say - life is learning

- Antti

[kevin_s2f]

What can I say - life is learning

- Antti

Completely agree. If you're not learning, you're not living. If you don't fall flat on your face sometimes, you're not trying anything interesting. Let's just say by that logic I have tried plenty of interesting things in my life. ;-)

[antti.rauhala]

Completely agree. If you're not learning, you're not living. If you don't fall flat on your face sometimes, you're not trying anything interesting. Let's just say by that logic I have tried plenty of interesting things in my life. ;-)

Well yes, it often works that way

Intellictual courage lead by curiosity enhances innovation and humility before reality enhances learning. From time to time it is both interesting and fun to push forward the boundaries, but the dark side of the process consist of the raising risks and the potential failures.

I guess represents actually rather fundamental question in the engineering world, some people advocating being innovative, developing and learning; and some people advocating just delivering and the near-future bottom line. It presents the two opposite ends, where it often seems, the best solution is compromise. It makes little sense to sacrifice productivity in the altar of learning/innovation, if the advances in productivity provided by learning are sacrified similarly in the future. Just concentrating on deliveries seems shortsighted sometimes, even if it works much better than the opposite end. 'Fortunately' (especially in software engineering) there are often many interesting problems blocking the delivery, and these goals often support each other.

Somehow still in industrial life, I have learned it as wise to focus on the goal and the delivery and - even - leave the fun stuff to the personal life. For work, Internet is a wondeful place to find out very quickly and learn efficiently from other people's failures in order to not repeat them and even for quite complex and interesting challenges the ready and shined answers await. In my own personal world, I can try out my own frameworks and neural network systems and really find out, what can and what cannot be done.