Applications and Service Platforms For Mobile User

Roland Piquepaille writes "ERCIM News is a quarterly publication from the European Research Consortium for Informatics and Mathematics. The July 2003 issue is dedicated to research about applications and service platforms for the mobile user. All of the 30 articles are available online. This column details the special constraints applying to the design of these applications: special interfaces, lack of power and memory, and interoperability between heterogeneous networks. In this longer column, you'll find a selection of stories, including links, abstracts and illustrations. Among other projects, you'll discover mBlog, "a mobile information service for all," or Fluid Computing, a middleware which lets "an application 'flow' from one user interface to another.""

Comments

Bigger Issue...

[mgcsinc]

While I recognize that it lacks relevance in the frame of the ERCIM newsletter, there is one particular problem plaguing mobile application and service providers: actual potential use by the customer himself. Issues such as special interfaces and differing platforms can be seen as unique design opportunities as well as challenges, and small availability of power, processing, and memory may be viewed as opportunities to weed out needlessly consuming code, but the general reluctance of even the most sophisticated enterprise users to take advantage of every mobile tool available - due both to the expense of mobile hardware and software systems and lack of true need for such tools - will remain a considerably more insurmountable obstacle for developers...

Re:Bigger Issue...

[Surak]

Lack of true need?

When the personal computer revolution hit, there was a lack of a true need for PCs. Nothing that could be done on the early PCs at that time couldn't be done with some other method -- whether manual or electronic.

It came down the killer app. And the killer app was spreadsheets. Nobody in the business world could IMAGINE this day getting by without a spreadsheet.

The Internet wasn't needed either. The killer app -- universal e-mail. Our mail server went down on Friday and there was MASS PANIC! OMG! NO E-MAIL! WHAT ARE WE GOING TO DO????

Strange how people seemed to exist before passing around memos and whatnot, isn't it? :)

Re:Bigger Issue...

[Wellspring]

I totally agree with this. I just got out of two and a half years spent working at a mobile application platform company, and so have seen the belly of the beast. Yes, the slow economy is the major reason for slow adoption, but there is another, deeper reason.

For one thing, a key piece of the industry, the wireless WAN providers, are simply not ready for prime time. It is very difficult to deploy an application over the air, and mostly this is for bureaucratic reasons. Carriers require long expensive certification processes for virtually any application, and often won't talk to you if you're looking at less than 10,000 installed users per app (not per platform or even per installation). Expenses are all out of whack-- bandwidth that isn't being used right now is inordinately expensive; the time to jack up prices is after the technology has proven itself.

The devices themselves leave something to be desired. I'm something of a device iconoclast; experience has taught me that frills sell a device but make it unusable in the field. Battery life, durability and ease of data entry are the three things that make the world go around in my experience. The RIM Blackberry, for example, is black and white, very hard to code against (I haven't played with the Java version yet) has no useful sound and barely usable graphics. It doesn't integrate with anything except Notes and Outlook. It is also my all time favorite. It lasts 2-3 weeks between charges, the text is clearly readable (if unsexy), the keyboard and thumbwheel are extremely usable (not as much with gloves on, but better than the touchscreens), and durable as anything. A coworker once dropped his out of a car, then pulled over and found it by the side of the road. It still was fine.

I'm multifunction device agnostic, too. Architecture groups at major enterprises go crazy for phone/pda combos, but I've found in practice that they do neither well.

OK, so all that aside, what does the world need in the way of PDA's and wireless to get mobile off and running? Glad you asked. ;)

1. The carriers have to drop the bureaucratic crap and offer clear pricing for wireless as if they were a wired ISP. Maybe that means per byte, maybe it means per month, but it has to be clear and flexible enough that if I pay or my company pays or their vendor pays, there isn't a 'technical' limitation.
2. The carriers need to get with the OS developers and build a remote kill switch library that every application must use. That clears up their legitimate concerns about bandwidth and bugs. With that, easy, outsourceable app certification needs to happen-- so you can kill apps that fail rather than holding every app at the gate waiting for them to be perfect. Ever wonder why BREW failed?
3. Device manufacturers need to recognize that devices are not 'small computers' but products with their own unique requirements. Look at what Symbol or Intermec are doing. Then stop putting MP3 players into your devices and start adding easy barcode scanning. Cut the color and extend battery life to a full working day at least. Handwriting recognition is 'cool', easy entry of data (possibly with gloves on) is critical. People will adopt these devices at home, but the consumer market is already more than adequately served.
4. Don't worry about standards. OK, let me ammend that. Don't worry about standards except for communications. The hardware is not yet a commodity; it is changing brutally fast. A company that commissions an app on a device buys 500-1000 of that device. When two years later they want to upgrade or change devices, they'll rewrite the program anyway, to take advantage of the new hardware. If the communications is standard, at least that won't change. Much. But give up for now on front end platforms-- worry about communications.
5. Software companies need to think about how people really work in the field. When you're in line for a plane reading your email, you don't wan

Fluid computing???

[stonebeat.org]

Isn't that just another name for XML????

Re:Fluid computing???

[GlassUser]

Eh, not hardly. Think serializing a data stream while it's in use and farming it off to the same application running on a different system. It even works well on different architectures as long as the binaries read the same memory map the same way (watch out for low- vs high-endian issue, primarily).

Re:Fluid computing???

[mmoser]

No, it's not just another name for XML. Its a name for the idea/vision that your application state can be migrated to (an)other device(s) at any point in time and even remain synchronized! I.e. you can not only migrate that document onto your PDA and then continue working on it during the bus-ride and later on your home PC (and back again next morning), but you could even share a document with other users at any point in time and changes by them could automatically be reflected in your copy.

The name tries to visualize that transferring/sharing an application's state should be as easy as pouring a glass of water into another vessel.

We were cought a bit by surprise by this early publication, so we don't have anything downloadable, yet. But we are working on it and there should be something available in a few weeks or so.

Re:Fluid computing???

[Anonymous Coward]

No, it's another name for VNC.

Re:Fluid computing???

[stonebeat.org]

I can get the same using a XML DTD (e.g. DocBook), and any user can use any XML editor, without worrying about formatting/presentation. i m sorry i m unable to see the difference.

Re:Fluid computing???

[mmoser]

"... (watch out for low- vs high-endian issue, primarily)."

Since the prototype is in Java (which takes care of such "details") this is a non-issue.

Re:Fluid computing???

[mmoser]

Ah, just a another name for VNC? And what if your network connectivity goes down? How do you then remotely operate your app? Show me!

Using Fluid you might not even notice, since each device has a version of the application and a full copy of the data. And the Fluid middleware takes care, that - as soon as the connection comes up again - the changes of the different replicas will be synchronized again in the background.

Re:Fluid computing???

[GlassUser]

That doesn't mean that all implementations have been or will be in Java. I can't see how it would be efficient in Java either.

RTFAs

[OoberMick]

All of the 30 articles are available online...
30 articles! No one RTFA's as it is, nevermind 30

Global

[some1somewhere]

What I'm really interested in are things that work globally, not just in one or two countries.

Just like in Japan... they have all these new funky 3G apps, that work no where else but Japan.

When do we get services and apps that truely work worldwide (just like roaming GSM and similar, but on the app level rather than infrastructure?)

Re:Global

[Talez]

A lot of the stuff is already cross compatible. Nokia for instance sells the same games worldwide via its Club Nokia service.

Most other things would need to be localised or at least need local partners to provide the data that these apps need to function.

As for video calls (3G's supposed killer app), I haven't seen any problems yet communicating internationally between 3G networks. For instance, you can make a video call between Australia and the UK and it works just fine (or at least Hutchinson/Orange says it does).

Re:Global

[makapuf]

when providers and standards do not diverge for strategic reasons.
On the beginning, 3G UMTS at 3GPP was supposed to be the unifying standard.

Until US & Asia said, damnit, we're not competing with others. Lets fork 3GPP with 3GPP2 or whatever and have our own standard ...

I guess this is not a technological reason. Like we settled on a worldwide PC hardware standard for untechnical reasons.

You could have said that about the web in general

[tgma]

One thing that the last few years have shown is that once platforms are built, it's very hard to predict which ones will take off, and exactly how they were used. I think that the same will be true about mobile data.

You are right to question the true need for such tools. How many of us really need to update our blogs on the bus to work? Of course, an account of a bus ride would be much more interesting than the drivel that you usually see in blogs, but you get my point.

However, I have found one perfect application for my SonyEricsson P800 - it takes the public domain stock prices, and displays them in an easy to read screen. This is much easier than going to a web page, which is going to be full of graphics that I don't want. I don't really need to send emails or surf, but this little app justifies GPRS to me.

I think that there is another question about whether this technology is going to be on the client or the server side. Designers may not be willing to adjust their code for every single device out there, even though I would dearly love to believe that XML can do this for them. On the other hand, if you can make a client side application that will strip out the useless information, or illegible graphics, this will ensure that content is delivered in a useable way. I think the app will have to be device specific: to use a trivial example, the mainstream games that have been ported to mobile devices, like Doom and SimCity, IMHO just don't work, because they were never meant to be used on such small screen real estate. It's very hard to anticipate every single quirk of every single device on the server side, so the work is going to be done on the client side, where the device knows exactly its own requirements.

What goes around comes around...

[mentalist23]

...details the special constraints applying to the design of these applications: special interfaces, lack of power and memory, and interoperability between heterogeneous networks...

IOW, everything HTML was designed to fix. (Or if you prefer, everything that CSS, font tags, etc subequently broke.) [sigh]

Am I allowed to comment before ...

[Mostly a lurker]

... I read the entire current issue and the other 35 issues currently available online?

At a first glance, this looks mighty interesting. I cannot believe I have not come across this material before.

Re:You could have said that about the web in gener

[kraut]

What app is that? I'd like to get that on to my P800 as well ;)

SkipWire was the ultimate

[SpyderFan]

SkipWire was able to upload and download programs and data from any Palm OS wireless device.

It did conversions between standard formats like .RTF, .DOC, .PDF, .JPG, .GIF, .PNG and the formats for the Palm, like PalmDoc, Fireviewer, TinyImage, etc.

You could do everything from your Palm browser. You could convert both directions and e-mail. It accepted e-mail attachments, and then converted them and made them available for download.

If you didn't have the right program to view the data, then it provided the links so you could download the free trial, and you could even purchase it.

If you didn't have enough memory, you could just upload something for storage, delete it, and then get it back later.

It was awesome!!!

It still works, but isn't very up-to-date. Probably a victim of the economy.

Palm, Handspring, or Sony ought to pick up the company and update it.

+2: 50% Karma-whoring, 50% for 2x in 24 hours

[HardcoreGamer]

Here we go again....

Roland Piquepaille: "This column details the special constraints applying to the design of these applications: special interfaces, lack of power and memory, and interoperability between heterogeneous networks. In this longer column, you'll find a selection of stories, including links, abstracts and illustrations."

TRANSLATION:
"I am a shameless karma-whore and copyright violator... OK, I'm just dancing around what I really mean: thief! This column [IT'S MY BLOG! AGAIN! DID I FOOL YOU THIS TIME?] details the special constraints applying to the design of these applications: special interfaces, lack of power and memory, and interoperability between heterogeneous networks. I STOLE all of it directly from the articles -- that's right, I plagiarized it as if it was my own work and added no value or original thought. In this longer column [MY BLOG YET AGAIN! DID I FOOL YOU THIS TIME?], you'll find a selection of stories, including links, abstracts and illustrations. All of that is stolen, too! The images, the text... copyright infringement is what I do best! Then I post it to Slashdot to build myself up as a technology pundit!

Somehow, I don't think the first part of "Liberte, egalite, fraternite" meant freedom to steal intellectual content that isn't yours. It's free as in speech, not free as in beer. As this poster (whose highlighting/linking of the issues has inspired me to do the same) pointed out, plagiarism and copyright infringement are serious matters that end up hurting us all. Rule one of trying to become an authority on anything is not to deceive, steal or otherwise break laws. Doing so ensures you have no credibility.

OH, THE HUMANITY! ;)

(I joke, but it really is a serious issue.)