Future of Browser versus Midlet Apps

[Byron Estes]

This is a question specifically directed at our guest author, but I'd be interested in hearing what other "ranchers" are thinking.
Do you think that browser based applications (HDML, WML, CHTML) will be largely eliminated by midlets and other forms of "light-heavy weight" clients or will there always be a place for them?
Have you seen many companies implementing business applicationss with this technology or this likely to remain a consumer apps technology?
Regards,

[Burk Hufnagel]

What do you consider a "light-heavy-weight" client?
Midlets are fine for PDAs and cell phones, but I suspect the need for browser based interfaces will be with us for quite some time. Mostly because of the lack of screen real estate.
Also, browsers give you much more control of the interface than midlets seem to (at least at my current level of knowledge about them) and many of my clients still want the kind of control they had with Windows based apps, so I think that will have a bearing on it too.
Just my 2 cents.

[Jonathan Knudsen]

Think bigger, Byron. The mobile phone is replacing the PC as the consumer's portal to the Internet.
There will always be a place for PCs, and for browser applications, but try to think in terms of "everyone has a mobile phone" rather than "everyone has a browser" in the future.
I don't know what's coming any better than anyone else, but the PC -> mobile phone shift is a big one.

[Lasse Koskela]

Originally posted by Jonathan Knudsen:
The mobile phone is replacing the PC as the consumer's portal to the Internet.

I agree with Jonathan that the role of mobile applications (as in J2ME, not as in WAP/iMode) is strongly growing. However, I do have some critique regarding "browser versus midlet".
If I think of what the handheld user expects from his mobile applications, my thoughts are definitely closer to J2ME applications than WML/cHTML browser applications. But. When I think of issues like deployment and maintenance, I really feel that the browser based applications will hold their position for some years still because of their "zero-installation" attributes.

[Burk Hufnagel]

I have no argument with the idea that mobile apps are coming on strong, in fact I think that's a Good Thing.
I also think that its a diffent market - some things just don't translate well to a small screen. Anybody up for reading/creating JavaRanch messages for on a cell phone?

[Byron Estes]

First, thanks for the replies.
I apologize, I must not have been clear in my terminolgy or my delivery, because (I think) only Lasse understood what I was trying to discuss.
Background...
I have already created a business object framework for one of the largest online brokerage firms to do wireless account access and trades (i.e. stocks, mutual funds and options). This common business framework was used by several presentation layer applications. All of which were browser based. Now, when I say browser based I mean mobile device browsers on a phone or PDA, not a PC.
I have played around with midlets to build simple apps, nothing commercial, yet.
When I said "light-heavy-weight" client I'm talking about any custom client built specifically to connect a remote service from a mobile device (i.e. midlet, brew, etc.).
I didn't find the shift from PC-based internet browser applications to mobile based browser application to be too difficult. There are some different considerations certainly: intermittent connections, network latency, data transfer size, browser limits/compatability issues, physically different device display/user interfaces, memory constraints, local storage, etc....
...but from an internet application perspective it's still basic "stateless" request/response. Security, to me, is one of the biggest issues due to the use of Gateways to convert the traffic to/from basic http exchanges that are vulnerable to attack.
So...what I'm really thinking about are trade-offs and reasons to use a mobile internet client ("thin" and generic/multi-purpose) versus a mobile "light-heavy-weigtht" client ("thicker" and single purpose).
Regards,

[Lasse Koskela]

Originally posted by Byron Estes:
So...what I'm really thinking about are trade-offs and reasons to use a mobile internet client ("thin" and generic/multi-purpose) versus a mobile "light-heavy-weigtht" client ("thicker" and single purpose).

Ok, here's my shot at it. I'm using terms "mobile thin client" and "mobile thick client" because they seem more descriptive to me than f.ex. "mobile internet client" which is kind of ambiguous.
Mobile Thin client
Pros

Standard, familiar user interfaces

No client installation necessary

No special system requirements for the device

Easier to add into an existing Web application (the communication between client and server follow the same principles as in regular webapps)

Cons

No custom widgets

No local data access

No real control over the presentation layer

Bad performance (as in "round-trip required for each action")

Mobile Thick ClientPros

Rich user interface (custom widgets, animations)

Access to local data storage

Full control over the application layers

Choice of communications methods (transport protocol, message format, encryption, etc.)

Offline functionality (auto-synch when going online)

Cons

Requirements for the device

Portability might be an issue

Deployment and maintenance needs serious attention

More complex to develop (you're basically implementing the V and C of MVC when the browser-type of solution gave you V and part of C for free)

Feel free to add to this. I must have overlooked something.
[ June 26, 2003: Message edited by: Lasse Koskela ]

[Burk Hufnagel]

Hmm. Seems to me that the reason you'd use thin vs. thick is the same whether on a phone or a PC.
If you need to have specialized controls on the screen or a specific layout then you'll need go the thick route. If it doesn't matter how the screen is rendered go thin.
If you want to store information between sessions then it's thick, or possibly thin with cookies - depending on how much info and whether it needs to be secure.
You get the idea.
Perhaps the bottom line is not a technical reason at all - which way do you think your users would prefer it? Can the thin version do what they want/need or do you need the richer environment that a MIDlet would provide?

[Michael Yuan]

Another key difference is that thick clients enable "offline" operation modes. You can sync your files every morning and go to work. Uninterrupted data connection is not realistic in today's celluar networks.

[Byron Estes]

I think Lasse did a nice job of laying out the tradeoffs. I also thought Burk made a nice point too, one that in my experienc many people who are just getting started with wireless don't realize: It's essential the same old stuff with a few twists. It's made a little more complicated because you're dealing with so many more platforms.
The only thing I'd add to Lasse's list as a con for "thin mobiile clients" is a problem we've all experience with "thin workstation clients", browser compatibility. Will it work on Netscape, and on IE. Does it support the necessary versions. The only thing with mobile is that there are alot more browsers, they are less mature as products and they don't always do a good job of following the standards.
Regards,

[Burk Hufnagel]

Byron,
Did you have a specific project in mind when you strted this thread? If so, which direction are you leaning - thick or thin?

[Lasse Koskela]

Originally posted by Byron Estes:
The only thing I'd add to Lasse's list as a con for "thin mobiile clients" is a problem we've all experience with "thin workstation clients", browser compatibility.

True. But on mobile browsers, WAP/WML for example, the incompatibility is not that big a problem (at least not yet). Could it be that WML is based on XML and is thus more thoroughly specified than HTML? Or because WML doesn't support as fine details as HTML with CSS etc.

[Byron Estes]

Burk asked...

Did you have a specific project in mind when you strted this thread? If so, which direction are you leaning - thick or thin?

No specific project. As I said I've done one major wireless product (online trading for a larger brokerage). We were required to use a thin client approach because it would reach the
largest audience.
Lasse commented...

But on mobile browsers, WAP/WML for example, the incompatibility is not that big a problem (at least not yet)

We had three different markup languges to contend with in the project I worked on: HDML, WML and CHTML (Palm). I have to say that the HDML and WML browsers were less of an issue from a compatability perspective the the CHTML on the Palm, but the GUI on the Palm was a little more complex because we had more real-estate to play on and the customer wanted a fairly complex navigation. We targeted two major browsers, Palm's basic one and a third party product (...which I won't name directly) that was a meta-browser for many different markup languages. Pretty cool idea, but we were working with version that was about to go to production that caused us to deal with some compatability issues. I used to have a list of them, but some were (in my mind) pretty severe. I'm sure they've worked out many of the issues since then. To me it's just like Netscape versus IE, except the number of vendors on the number of platforms (phone's and pda's) you may encounter is increased dramatically.
Regards,

[Lasse Koskela]

My statement of "(mobile browsers') incompatibility being not that big a problem" was partly based on the fact that standards like WML and cHTML are not yet being stretched into their limits as was HTML's faith. For example, nobody's expecting to be able (I hope) to define to a pixel detail where an image should be placed on the WML browser window.

[Greg Schwartz]

The issue of "mobile thin client" vs. "mobile thick client" is definately becoming a big source of debate as midlets are becoming more and more popular. There were a lot of interesting points made in this thread that I think the previous posters did an amazing job comparing the two.
I really think a big aspect of the midlet advantage is the end user experience that comes from having the application run on the handset. There seems to be tremendous delays when using web-based solutions on mobile devices. Every screen change requires network activity so this ends up being a pretty serious downfall. I think that having the ability to control when an application uses network connectivity is a huge advantage for midlets.
As the majority of phones become Java enabled (75% of all phones are expected to be by 2006) and as it becomes more common to download apps diretly from the handset (instead of having to use a desktop web portal) midlets will increase in popularity. Hopefully carriers will make an effort to promote J2ME apps the same way that mobile web apps are being hyped. As for now, the fact that mobile web applications require no installation is a big advantage and a great point that was brought up earlier in this thread.
I guess we'll just have to wait and see what happens....

[Michael Yuan]

In my opnion, WAP has given "Mobile Commerce" a bad name. WAP based e-commerce has been available since 1998 but it never took off. It is a failed experienment because it assumes reliable and high speed data networks that simply arn't there. Also, WAP cannot take advantage of device extensions such as camera and GPS modules.
So, I am really annoyed when people equate mobile applications to a "presentation layer in WAP". That is just wrong.

[Lasse Koskela]

Originally posted by Michael Yuan:
I am really annoyed when people equate mobile applications to a "presentation layer in WAP". That is just wrong.

Ditto. On a job interview, the interviewer enthusiastically listed technologies they were using in projects... Java, J2EE, J2ME. "Wow, finally I get to do J2ME," I thought. Later on the truth was revealed: the "J2ME project" was actually a WAP site. Fortunately, I got to choose what I want to do so I went J2EE and got a nice little integration middleware component to build
But regardless of the bad name of WAP, I personally think it's a good technology. The problem was bad expectation management, not bad technology. I don't think the slow network is that bad for typical WAP applications. You don't need to know tomorrow's weather at your summer cottage right now -- 30 seconds should be quick enough.

[Byron Estes]

I am really annoyed when people equate mobile applications to a "presentation layer in WAP". That is just wrong.

WAP is simply one choice of many. The application, the devices to be used and the audience to be reached should always drive the choice of the technology. People simply need to look at the business need and the tools at hand to select the what's right for the situation.
Midlets are not going to solve the network woes. They can provide some options and make dealing with the connectivity bumps a little easier, but only marginally. Application service consumers are notoriously impatient and usually not very saavy about the technology they use. If they need to wait, they usually aren't too happy about it. The networks will get better, I just wish we would be more standardized like Europe and parts of Asia.
Regards,

[Michael Yuan]

Originally posted by Byron Estes:

Midlets are not going to solve the network woes.

Yes, to a large extend, they can. The most successful mobile applications today are the plain old Palm PDA or PocketPC apps which have no live network connectivity and require synchronization everyday. I agree that we have to choose the right tools for the job. But synchronization based smart client solutions seem to the sufficient for most of today's game or enterprise tasks. When you have MIDlets, you can synchronize many times everyday. "Offline" is where MIDlets really shine.

[Byron Estes]

I think we're agreeing to an extent, but I "think" my main point may be getting overlooked...
You indicated that you believe that midlets can solve our network woes to a large extent.
I know what you're saying and I agree that being able to perform tasks on the device without having to be connected for everything is very helpful and can make being disconnected easier to deal with.
But it's not going to help when you have a time critical event where the device must have connectivity in order to compete some business transaction. Some problems like online trading aren't going to be helped by this, the market is moving and time is critical. It's the nature of the beast...
The ability to have a disconnected application that relies solely upon syncronization via the cradle when connnected to you PC depends upon the business problem you're trying to solve/alleviate. If it's a game, a basic office application or a data collection tool, that's fine...but not all appplications can fit/embrace this mode of operation.
Midlets do give you a broader range of choices with regard to where logic can be placed in your application layers....but with that benefit comes responsiblity for the developer to choose very wisely.
Because there choices create other issues that must be addressed/considered as the application is upgraded. Resyncronization of components, changes to local data storage, conversion of that data if necessary due to the application upgrade etc.
Have a great weekend!

[Michael Yuan]

Hi Byron,
You are absolutely right that the "occassionally connected" paradigm is not suitable for every situation. I certainly agree. On the other hand, even for real time applications, MIDlet is at least as good as WAP. When the network goes out, MIDlet applications, at least, can fail safely.
Also, for the financial trading example, MIDlet applications provide end-to-end HTTPS security and support transactions. WAP-based solutions support neither. But that is another story.