Everything and the Mobile Software Universe…

Good read at edschepis:  Is still there any Java ME Programmer Thinking in Object?.

I’ve always been myself an Object Programming advocates … if you know what Object Programming is! And after a lot of interaction with many developpers, frameworks, etc:

• Object Code is great if you know what you do, what is the philosophy of objects, self containment, inheritance, etc. But MANY people don’t know what is an object, they code Java/C++ as if it was in C, leading to code bloat, bad maintenance and performance.
• Object Interface are…hum counter intuitive: you never know what object to create or what function is really called if you don’t have designed yourself those objects: object are great for YOUR code, but not so great for libraries where your user won’t know/master all the maze of your object graph (have a look at Symbian APIs … far from being intuitive).
• Many time it may hide some very big CPU/RAM issues, but it has more to do with the associated libraries, like the STL (see my previous post about that performances trade off) .
• …did I say that I like Object Programming? .

:: mobiface :: next gen mobile interface thoughts

Be sure to read the three quoted links:

• UI “cruft” : …wow refreshing to see why our OS are so counter intuitve … ouf, I’m not completely dumb , check also from the same author: Why Free Software usability tends to suck.
• The Monkey Experiment : no way, read this one…and get free!
• This Is What Happens When You Let Developers Create UI this is sooooo true…:

from Mobiface also: Interfaces as art that links to a great design site pingmag

with a very nice article about art and phone UI Here are some examples:

Look at the contrast between the four above images and the first one…no comment.

It should be forbidden for a Software Designer to design any UI! To do that Designing UI MUST be done with non dev tools, but authoring/design tools … Seems obvious, but really not the case in the real world .

Here is a “Joel on Software” analysis of the MS Vista menu .. and its, hum how to not say something rude, surprising number of available user choices .

The real fun comes just after, when Moishe Lettvin, that was in charge of the developpement of this feature
gives its explanations!…Lenifiant, and “ubuesque”,

…24 people involved in this feature. Also each team of 8 was separated by 6 layers of management from the leads, so let’s add them in too, giving us 24 + (6 * 3) + 1 (the shared manager) 43 total people with a voice in this feature. Twenty-four of them were connected sorta closely to the code, and of those twenty four there were exactly zero with final say in how the feature worked. Somewhere in those other 17 was somebody who did have final say but who that was I have no idea since when I left the team — after a year — there was still no decision about exactly how this feature would work.

moblog: The Windows Shutdown crapfest

Really really something to go through…cause it seems that all kind of organizations may tend to those limits. And it is a good list of what NOT to do, or try to not do when your business is growing bigger….

But things can be different, look a little at Google:

From a high level, Google’s process probably does look like chaos to someone from a more traditional software development company. As a newcomer, some of the things that leap out at you include:

- there are managers, sort of, but most of them code at least half-time, making them more like tech leads.

- developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.

- Google has a philosophy of not ever telling developers what to work on, and they take it pretty seriously.

- developers are strongly encouraged to spend 20% of their time (and I mean their M-F, 8-5 time, not weekends or personal time) working on whatever they want, as long as it’s not their main project.

- there aren’t very many meetings. I’d say an average developer attends perhaps 3 meetings a week, including their 1:1 with their lead. – it’s quiet. Engineers are quietly focused on their work, as individuals or sometimes in little groups or 2 to 5.

- there aren’t Gantt charts or date-task-owner spreadsheets or any other visible project-management artifacts in evidence, not that I’ve ever seen.

- even during the relatively rare crunch periods, people still go get lunch and dinner, which are (famously) always free and tasty, and they don’t work insane hours unless they want to.

These are generalizations, sure. Old-timers will no doubt have a slightly different view, just as my view of Amazon is slightly biased by having been there in 1998 when it was a pretty crazy place. But I think most Googlers would agree that my generalizations here are pretty accurate.

How could this ever work?

Stevey’s Blog Rants: Good Agile, Bad Agile

And read the whole article also cause it is a refreshing rant about Agile … and a good insight at Google success…and why everyone wants to work there!

Perhaps you’ve heard a lot about ULC (Ultra Low Cost) cellphones in the industry (many companies are aiming this market, see The Motorola F3)…but they are targetted to new markets, where text rendering/input is really more complex than our relatively simple alphabet: it is mandatory if you want to reach the mass of Indian users, Sri Lanka, Cambodge, Hebrew, Arabic, Philippina , Chineese…and you want cause “texting (smsing)” is a big thing: else your new emerging market will be limited to eastern Europe or South America, and be sure that text messaging will continue growing bigger. Look at the buzz around hotxt (read this mobHappy article about this new service, even if it is all but positive about it or at SMS Text News, please check the comments on this one… ) or Berggi (Berggi GigaOM article, I’m not sure about the business model of such an offer, 10 bucks a month to send sms!!). IM is perhaps the next text heavyweight champion (check this techCrunch article about the next bif ideas around IM)
So Text IS big and will stay big…so emerging markets have to have the tools to leverage this potential!

Two different issues to be fixed araise:

• Text Rendering
• Text Edition

In fact text edition is not so diverse and different accross the languages: the T9 you know is not so far from Chineese input. At the end you only have two kinds of predicitve text input methods:

• One for alphabetic languages, the one you have on your phone today. For those languages multitap is also of course heavily used
• One for “ideogram” languages (hum, only in China/Taiwan and Japan (kanji) in fact ), with Pinyin, Strokes, Bopomopho input being some variations

And after having implemented both in real life here at Open-Plug…the alphabetical one is in fact more complicated!
Two companies have the lion share for the predictive engines:

• Tegic (now AOL) and its T9 offering, more Western countries oriented
• Zi corp (eZiText, eZiTap), more Eastern oriented

Both have great products and large and complete languages databases, for me their biggest IP. Cause once you have a predicitve engine the real pain only begin…the UI and user interaction around those dictionnaries is really really complex:to give you an idea, the specification of text entry methods and use case represents more than 25% of the whole UI specification! and of course, for each phone/vendor/carrier it changes, so integrating T9 or EZiText really means if fact tayloring YOUR existing text entry framework for a given specification, the predicitve engine being only a little part of the whole thing. We ended up, in collaboration with LiPS to create a real “Text Entry Framework”…

So let’s move to the text rendering part…
Many companies are developping solutions to render text…so why such a fuss? After all it is only about drawing characters on the screen no? For us, with our simplisitc alphabet european languages, it sounds like something trivial…IT IS NOT, cause complex languages are REALY COMPLEX.

• First you have the magic around Bidirectional text (for those crazy men that are writing from right to left, Hebrew, Arabic…I’m sure they say the same for us writing from left to right )… you will say it is only printing in reverse….you couldn’t be more wrong, simply look here for the full specification of the bidirectional algorithm, hum, simple isn’t it? How to insert left to right text in a right to left paragraph, how to wrap in that case?
  
• Then you enter the brave new world of GSUB, GPOS ans co. In some languages some characters are mixed together and inversed to form a new character: the logical ordering (in memory) is really far from the display ordering. Champions in those kind of games are Devanagari, Indic, Thai…
  

So to handle all those languages, a solid text layout framework (for character clustering, reordering, wrapping) is needed, and a good font renderer. The open source community has developped Pango for the layout and Cairo for the rendering. ICU, from IBM is also a well known open source text layout engine.
Anyway those projects are huge, a big linguisitc knowledge is needed (try to debug a devanagari string…) so to have a quick working solution the industry offers you partners…and many exist, showing that this is a real issue!

• nCore :a little finish company that has a full Layout+rendering engine and a rich text editor, we are working with them already : their solution is really great, fast, light, etc, plus they are darn good at what they do. Their core busines is not font, but rendering.
• Tegic (T9) has a solution (seems to be based on nCore technology), adding their own features and a good integration with their text input solutions
• ZiCorp has also a solution that can be integrated with predictive text input solution
• Monotype, a 100 years company that invented the Arial and Times New Roman fonts…they know well how to render texts , their market is more toward the fonts themselves
• Arphic a taiwaneese text rendering vendor, I don’t know much about them
• Bitstream, a US text rendering vendor, with a solid technology. Also more “Font oriented”, and vector based
• Microimage, I’ve heard of them thanks to 3GSM Asia, but for now I don’t know much about their technology

So to play seriously in the ULC field the phone software needs a very solid text solution…and really it doesn’t come overnight! And be careful when designing/implementing/choosing your solution/partner: it won’t run on smartphone but on ULC phones, so no extra RAM nor CPU, and here CPU IS a challenge. Aslo don’t pass on it, people are really not willing to simply learn english

This DevX article: Get to Know uSTL: A Lightweight STL for Symbian describing a symbian STL (C++ Standard Template Library, the C++ “toolbox” with lists, vector, string utils, etc.) less crippled that the standard one, really reminded me of this eternal debat.

Recently we have worked on some memory optimization for our product, the part running on the PC. It was using way too much memory compared to what information was effectively loaded.

The data model is XML, and we are creating our objects with SAX parsing of this model… and many things were stored in STL string, and some stream where used….surprise STL string where using 128 bytes preallocating data…so for a 4 bytes string you use …. 128 bytes! stream memory use were growing exponentially!

So we played brut force and quickly reimplemented a class string based on good old char *, and a stream tuned for our use…and guess what: mem usage was divided by 10, and it was really faster.

Conclusion of this story: if you want to go serious, you have to master and well understand all the objects you use heavily: It may sound obvious, but many many time programmers take too many things for granted, especially on the PC world ….you know why Windows is now using way too much RAM …but in the PC camp Moore Law helped a lot to deal with RAM/CPU power explosion…

It is not to say that STL is a bad library (ok, not so intuitive to use, but it is another story), but those kind of services are ok for prototyping, or “normal” application, not for intensive ones. The difference between this two kind of applications is blurry, and coding something faster prevails way too often, heading to crippled apps.

Now look at the mobile phone space, here the Moore Law is not bringing a lot of RAM/CPU, it is “only” bringing down the chipset cost…but the vast majority of mobile phones are still running on CPU with less that 10 MIPS and 256 or 512kB of RAM, BUT feature sets are still growing and growing….

So obviously your applications, services, HAVE to use less RAM and less CPU each time, hum we are really NOT in a PC world.

To achieve that you can:

1. Continue to code as close as possible to the bar metal (uhm silicium), using low level C code, assembly, few OS services.
2. Use a Mobile Phone coding framework, taylored for the embedded space (this one is itself made using the previous point mode of programming), with a native programming language (C/C++)
3. Use a Higher Level OS with a native programming language (C/C++) (Palm, WinCE, Symbian)
4. Choose an “interpreted framework” like Java or .NET (see the Mono effort in this respect)
   
5. Go for scripting. (like OpenLaszlo, Ruby On Rails, Digital Airways, etc)

Of course the more abstract you go the more RAM/CPU you loose, but the more developper productivity you get … if you stick too closely to the PC world mantra. BUT if it doesn’t fit in your target …. it won’t fit , and you loosed a lot more that productivity, you loosed your market.

A high Level OS is simply not a choice: try to fit WinCE in a 10 MIPS machine … it is already not snappy on a 400MHz ARM 926 … (same for Symbian and in less extent Palm)

So things have to be more balanced, and as the zen approach told us “the middle way” may be the solution.

I strongly believe that a mix of very high level services for UI, with a good interconnection with low level services for control, algorithm and modelling part of the application is the way to go:

1. You let the graphists/designers quickly design your UI
2. You code the algorithm, controls, threading model, network in C/C++ with low level or very low resource consumming APIs
3. You let the framework dealing with interactions between applications and resource access sharing.

The last point is crucial, else you end up with a big mess, with unmaintenable and non evolutive code cause all the services will have to know each others, definitively a big mistake. The first one has to be there cause clearly the UI is, in this market, defined in specifications by UI specialists, and it can greatly improve the time to market to let them “design to manufacture” with some powerfull tools to create UI, like user friendly RAD, or even better like Flash Lite SDK, or Digital Airways But those high level solutions are not enough cause they lack the second point: the logic of your app have to be done in a scripting language, which is clearly not tuned nor designed to do that: UI and Logic HAS TO BE more clearly separated to use the best tools to do the job.
Java also doesn’t fulfill those needs … SavaJE is not everywhere, no phone with full Java UI…(I won’t go also in the Java mess around standardization, check this techtype entry about internationalization ): It is not good for UI (only a programmer can do a UI), and so so for application core (CPU and RAM, plus missing APIs).

For sure, as said at TomSoft we need Mobile Developement Simplification(and yes widget standardization can help), but the traditional vision of “one model” fits all seems clearly not relevant for our industry, and more innovative frameworks have to emerge to trully allow the explosion we are all waiting around mobile services (see this entry about skype failure to deliver…).

What do you think?

Update: Taken from the Adobe Flash Lite 2.1, here are some RAM/CPU for flash …

Ok, we are far from the “Ultra Low Cost”/”Low Cost” segment but not by a 10 factor (except for CPU), so suing only some part of flash for a phone UI is not out of question ….

Update 2: Good read at “C. Enrique Ortiz Mobility Weblog” about the C language, and why it is still, and will stay, usefull. Anyway for me C++ is also a “low level” language as it is compiled and you are dealing yourself with pointers …

In this blog we talk a lot about developpement frameworks in the mobile space, which are close to “traditional” framework (like GNOME, Qt, Windows, MacOS, even Java in less extent), but newcomers are popping … from the web space.
I’ve played recently with a great CMS (hum : a blog engine on steroid) Drupal to developp as quickly as possible an in-house test cases/release quality report system for our test teams, a weekly tracking tool for my team and some other stuffs: I’m NOT a php/javascript/XML/HTML junky, I’m a C/C++/algorithmics dev, and … doing that was EASY and FAST, and I must say efficient.
The biggest positive points that have popped out:

• Documentation of PHP/Drupal : amazing, clear, dense, …neat
• Data formalization (RSS feeds and XML)
• Powerfull presentation framework that let me concentrate on the job

If we compare those point to exisitng frameworks, some are really missing : Documentation of course is not only many time missing, but when it is present, it has been written by code monkeys, certainly good at coding and architecture, but not for teaching and giving fun (I’ll quote here one of my Kathy Sierra favorite post never underestimate the power of fun). Data formalization: it is a joke today in the C/C++ world, where is easy serialization? Database?. Presentation framework : ok you have some exisitng but you still have to fight with widget mechanics…boring and bug prone.

It is where new web frameworks may bring something new, I’ve spotted 2 at this time:

• Ruby on Rails
• OpenLaszlo (found again via TomSoft)

Ruby on Rails is really pushing the MVC (Model View Controller see my post here and here) paradigm to its limits, with a clean high level language….I’ll try to use it as soon as possible.

OpenLaszlo claims to bring the desktop power to web applications … and the approach seems greats (look at the examples) : the UI is described in clean XML, then everything is compiled in Flash or DHTML, AJAX stuff/javascript are hidden.

So it will be time to bring this kind of technologies to mobile developement … and constraints… Flash today is perhaps too RAM and CPU consuming (but I’m sure it will change). Making things too easy has also its drawbacks, especially in an area where customization is a key differenciator, see also this Kathy’s post about ease of use.

At Open-Plug we already have a clean, all recoded GTK that is running on Ultra Low Cost phones with no issues, for me the next step would be to add some more formal and high level UI descriptions, and some better data modeling to come close…We have begun, and it is exciting!

Linux not ready for mobile phones, Nokia exec says and this about some experiments they are working on: Nokia turns cellphones into webservers
This is pretty interesting and gave a good balance to the “all on linux” message.
At the end, what really matters are the services offered by th eplateform, and not the kernel…if you have the malloc/fopen/socket functions, do you really care if there is a linux kernel to implement the functions ? Guess no, only the services and their description are relevant, not their implementation, to digg this idea, see my post: Does mobile OS matters : no, it’s all about function. in response to this great one at Mobile Opportunity.
So nokia wants to run some “open-source” services (a browser, Apache) on their phones … and has realized that Linux is NOT mandatory to do that.
To come back to the web server article, I’ll quote the following:

[...]

• Interactive, contextual, and location-dependent content
  • Use the phone as a webcam
  • Find other mobile web sites in the proximity
  • Find out the location of a mobile website (cellid)
• Enabling new communication means without operator involvement
  • Send instant message
  • Leave instant message in the inbox
  • Leave a note on a mobile weblog
• Access core data
  • Access favorites, contacts, calendar, logs, and messages
  • Download images
  • Mount a read-write view of the root webserver directory and edit pages directly using WebDAV

[...]

The second point is particularly interesting: no need of the operator nor centralized servers to create services…the phone makers are back in the game to master as much as possible user content and phone usage…For me many things can be read between the lines with this experiment, pretty exciting to say the least!
Any comments are welcomed!

Interesting read :
Agile Chronicles: Can Gantt Charts be Agile?

We try to put in place Agile methods here, but even if as software developpers we strongly believe in the iteration process and so one : we have traditional clients that need to know Date/Schedule/What is in a release/Is the project going late? by how?. And for me, and for now, even if Task/user story are “agile” in our process, I need a Gantt Chart to give DATES/DEADLINES/SCHEDULE to my hierarchy, taking into account my team holidays, the impact of bug fixes vs features coming from different clients.
I’m incomfortable in respect to Agile methods because of this deadline thing:

• Either client/management has to adapt and forget the deadline stuff, accepting many incremental changes and releases….hum forget the incremental release stuff in the embedded space, with those awfull build systems.
• Agile has to be adapted to present a Schedule and Deadline frontend … because it is what PEOPLE understand, forget team velocity, % completion, etc, the only things clients/hierarchy want to know is by how much days you will be late

What do you think? what solutions did you put in place to make Agile compatible with businesscases?

Great read from TomSoft about Mobile Ajax:
TomSoft » Myths of mobile Web2.0 (and mobile Ajax).

Really in line with what Thomas said, especially this point :

…Ajax applications will run the same on mobiles than on PC, and this will save us some porting costs. Wrong! Seems that the Write Once Run Anywhere myth is back!! It was actually already not achievable through technology designed for this, so I did not see how Ajax app…

Same for me … the more I work in this industry with european, chineese,Korean partners the more I see:

• How skilled they are
• NO UNIFORMITY : for each client, and even for each phone for each clients, many things are different and can’t be abstracted generalizing a concept.
• Requirements are from Operators (Carriers), Graphic Designers etc… and no one has the same approach for UI and data representation…

A good technology should help this diversity and free the creativity of those actors… wrong idea to lock them in one scheme, one way to do … how will they differentiate?
Customization is key, and is not at all limited to theme, colors and image, but of the whole software …this is our vision here at open-plug

Suddenly everything’s coming up widgets – September 1, 2006 Is an interesting introduction to the widgets and why this concept is successful:

…In the early days of the Internet, most companies would create a destination website, wait for users to show up, and then make money from the advertisements. Now they use widgets to reel users in.

A Gmail widget on someone’s desktop that shows “10 unread messages” will make that user click and go back to the Gmail website, where the ad-based cash register goes ka-ching! Microsoft (Charts), AOL (Charts), Yahoo (Charts), and even Nokia (Charts) are also offering widgets. …

And …:

…Of course, the main reason widgets are hot is that users love them. That’s because they help to make the Web user-programmable…

So it has something to do with advertising for now : display snipets of information …. to attract user more often to advertized content.

As for RSS feeds the “data” coming from the content provider is highly minimized and standardized, and IS PUSHED to the content consumer; then a local “application” or service is displaying it nicely according to the system on which it is running: the winning equation seems to be again a strong separation between the content and its representation (as everything around XML, PUSH mode instead of passive publication plus a good standardization and description around the content itself : it reminds me of the microformats concept (see this great microformat blog for more information) and the concept behind Ruby on Rail …

Looking for links for this post, I’ve found this interesting MVC introduction, worth a read if you don’t know it!

UPDATE: I’ve crossed this post just after this one: Open Gardens: The implications of ‘Data is the intelligence’ on mobile software development the data IS the value. (found from the excellent “Carnival of the Mobilists” of this week)