FORUM PLAN UPDATE: Date revision: This forum will remain open to new posts and responses until December 1, 2018. (After that date, you will still be able to view and search the forum.) Also, we're taking a second look at the best place to host future conversation. For now, keep using this forum, and stay tuned for more news.
Is it?... re: Ridiculous Nathan T. Freeman 10.Dec.02 12:45 PM a Web browser Notes Client 6.0Linux - RedHat, Linux - SuSE
OK, I looked at the BP forum, which is a fairly active and fairly typical
Notes discussion forum,
A discussion populated almost exclusively by people who are supposed to be
experts in Notes is "fairly typical?"
At least (since I was very conservative) 15.5% use features that are not
available in the edit control from the web.
15.5% use the features. So 84.5% don't. What was my threshold number again?
It is not fancy API stuff that makes the Notes client so powerful, it is
the powerful rich text editor,
Have you fired up iNotes lately?
the spell checker,
You have GOT to be kidding. The workspace as a piece of key functionality?
Puh-lease, Ben. The only reason the workspace remains so prevalent is the fact
that building usable corporate portal systems in Notes based on profiles is too
much of a pain for most organizations to bother with.
the formula language that isn't available from the web client,
Can you tell me the things that are possible with @functions in the client that
I can't do in web clients? The entire point of the Domino server is to handle
this need for you.
the UI classes that aren't available from the web client.
The Notes client UI classes pale in comparison to what I can do with the
the caret position in the NotesUIView is relevantly useful but unavailable to
You can simulate some of these, but the Notes client is hugely more
powerful than the web browser,
If you can simulate it, then the functionality is available to the user, and my
and it takes way, way less work to do most things that are designed for a
Notes client than to do the same for the web.
It's easier to work with a smart client than a dumb client? No surprise
there. But I said functionality, not development time. And when you can build
something in X time that will work with 90 million clients, or build something
in 3X time that will work with 500 million clients, there's certainly a good
reason to go with the latter.
In addition, many companies have many databases that are only used in the
Notes client, and that would pose insurmountable challenges and costs to make
available on a web client.
It's no secret to me that these applications are out there. Care to guess how
many of them I wrote? But if they pose "insurmountable challenges and costs,"
I'd suggest those companies contact me. firstname.lastname@example.org I'll be happy to
take on what's insurmountable and what's not.
If there were a Linux client, they would not have to, so the "cost" of
any Linux web clients is greatly magnified.
If the applications are that critical, and the challenges to move to the web
are insurmountable, then the company's willingness to pay extra for a Linux
client should be the delta between the TCO for Windows clients and the TCO for
The problem is, the TCO for Linux at the desktop is turning out to be *higher*
than for Windows at this point, mostly because Linux expertise is more
I'm sorry, but for the ordinary user, the difference between the Notes
client and the web browser is in no way 80% of the functionality.
I can't pay for it, but I would be happy to participate in a usability
comparison lab with you on this. We just need specs for, say, 4 fairly simple
applications, one built for the browser and one built for the client. Then we
can see what level of functionality is achieved in what platform.
Maybe for simple e-mail, but not even for calendaring and scheduling.
So 1/5 of the capabilities of the native C&S client are unavailable to iNotes
clients? Do you have a list?
It is just a ridiculous assertion, mush as I respect you, Nathan.
I'll be happy to compare individual feature lists. You can't just through
something off like "@functions." @Functions aren't user functionality.
They're a programming tool used to achieve user functionality. Which means
they can either be interpretted by the Domino server (@userName) or mimicked
using other programming tools (@DbLookup).
Unfortunately, it is all too common a misconception.
If it's a misconception, I will gladly accept substantive counter-argument.
Shall we list out 100% of the features of the native client, then list 100% of
the capabilities of the browser as a Domino client, and count 'em up? I'm game.