Andrew Pollack's Blog

Technology, Family, Entertainment, Politics, and Random Noise

Fixing Domino Designer -

By Andrew Pollack on 06/15/2010 at 11:47 AM EDT

I’m limiting this post to things specific to fixing the Domino Designer Client. I may talk in another post later about next steps and new features, new design architectures, library interfaces to other design tools, and changes to the client strategy – but for now those are off limits.

First – Move XPages to a standalone tool. The XPages application has no business being inside the old Notes Designer Client, and keeping it there has a strong negative impact on one of the key goals of XPages – attracting new developers. Creating an XPages design tool that can be installed without DDE and containing elements designed solely around XPages would free that team to creating a truly modern user interface without wrecking the existing tools. Minimalism is the key.

Second – Hire or train people to become experts in rich text and form design layouts. Those skills have been largely lost through layoffs and attrition, resulting in an abject fear at IBM of actually modifying that old code. That just irresponsible and frankly pathetic.

Third – Fix the bugs, stupid little workarounds, and half done features – all of them. Spend a full development cycle if that’s what it takes. What do I mean by this? Example: You can select a subform in another database by menu at design time, but you cannot do it with a computed subform. You can use @GetDocField – but only if the target doc is in the same database. BOTH of these are missing nothing more than the ability to add a “server”:”database” parameter the way other lookup function were smart enough to include back in 1992.

Fourth – Deprecate some features that never worked right. One of the things holding back changes to Forms is the need to support features that failed from day one – like layout regions. If there are little used, poorly functioning parts of the product then it’s time to allow some backward compatibility failure through a rational deprecation process.

Fifth – Start adding modern feature sets to the core product. I’ve got a list of those as I’m sure many of you do. We need to save and refine that list – but first we need to fix the damn base.


There are  - loading -  comments....

re: Fixing Domino Designer - By Darren Duke on 06/15/2010 at 11:56 AM EDT
1) Erm....XPages was standalone. No one used it (LCD I think).

3) and the 32K and 64K limits on stuff.....
re: Fixing Domino Designer - By Andrew Pollack on 06/15/2010 at 12:03 PM EDT
When it was LCD, it didn't really integrate with Notes data well at all, and it
required a standalone portal server to run its applications. That alone was
enough to kill it.
re: Fixing Domino Designer - By Tim Tripcony on 06/15/2010 at 12:08 PM EDT
I'm definitely in favor of a standalone XPage editor for several reasons. I
expressed one of those at Lotusphere this year during the "Meet the Developers"
session: everything in Designer related to XPage development - not just the
actual XPage / custom control editor, but also the editors for SSJS and custom
Java classes (NOT the old Java script libraries... which is a ridiculous bit of
terminology to begin with) - are "pure" Eclipse. The implication of this, of
course, is that a port to Linux and/or Mac would be a comparative cakewalk,
whereas the editors for traditional design elements like Forms and Subforms
would likely have to be rewritten from scratch. If they would just give us a
non-visual editor for Forms and Views, but keep the existing format for
everything directly XPage-related, they could plop all of that into a Eclipse
distro that runs natively on Ubuntu... and I could ditch Windows entirely.
re: Fixing Domino Designer - By Andrew Pollack on 06/15/2010 at 12:12 PM EDT
Yes! Tim that is exactly my point. Having to live within the old designer is
detrimental to XPages -- for the reason you mentioned and many others, while it
also is detrimental to the old DDE.

A standalone XPages client could be a better development environment for doing
XPages work and might even be able to meet the goals of attracting some non
domino developers.
re: Fixing Domino Designer - By Richard Shergold on 06/15/2010 at 12:14 PM EDT
Agree. And wouldn't "I develop in IBM XPages" have a better sound to it
nowadays than "I am a Lotus Notes developer".
re: Fixing Domino Designer - By Peter Presnell on 06/15/2010 at 12:44 PM EDT
Andrew I agree 100% with your suggestions.

A lot of people love the relative simplicity of the original Notes Designer.
Making it even simpler by removing some of the old stuff that no longer has a
place would make it even better.

Having a separate Lotus XPage development product works for me too.

Two distinct products marketed at two distinct target audiences would allow IBM
to develop two distinct marketing messages that may resonate a whole lot
clearer. I wouldn't mind if 75% of future investment goes into Lotus XPages as
long as some attention is given to modernizing the original concept.

There may also be a need to find a way to address the eclipse (CA) side.
Having form/view attributes that only work within a CA is adding unnecessary
complexity.
re: Fixing Domino Designer - By Karl-Henry Martinsson on 06/15/2010 at 01:08 PM EDT
Great suggestions!

I think that Lotusscript need to be updated and improved as well. I know
Nathan, Tim and a bunch more will not agree with me, but I have a reason. And I
don't think I am the only one in thsi situation.

I am still stuck on Notes 7, but hope to get up to Notes 8.5.1(?) around the
end of the year.
But I doubt there will be much XPages development, at least not initially, for
me. I not have the time right now to learn it, with having to take one some
workload from my project manager who left in January. So I do not have the
luxury of spending several days or a week to do something in XPages that I
could whip out in "traditional" Notes using Lotusscript in a day.

And all my agents are still written in Lotusscript. I will not start rewriting
them in Java, just to add more functionality. They will be maintained in
Lotusscript. Why deprive me of new functionality then?
Isn't that what we all brag about with Domino, compared with Exchange? "No
rip-and-replace to get new/better functionality."
re: Fixing Domino Designer - By John Head on 06/15/2010 at 01:41 PM EDT
but for everything that people say takes a week in xpages and a day in
LotusScript, there are just as many opposite features. Most importantly, I can
build a 2.0 UI that users enjoy using very quickly. And once I have a corporate
theme - I can reuse that with a couple of clicks.

Plus, you can reuse so much of your agent code. Sure - over time it makes sense
to move stuff to SSJS.

Let's be honest - traditional Notes dev can't compete with
.NET/Sharepoint/Enterprise Java/other Web 2.0 tech. Users want something great
to look at and use. Developers want modern tools. IT Managers want tools and
technologies they can hire for and will enable lower management costs.

Andrew, I see what your saying, but I think the moment you split of XPages from
Designer, Designer goes into pure maintenance mode.
re: Fixing Domino Designer - By Andrew Pollack on 06/15/2010 at 01:46 PM EDT
John - I make pixel-exact sites based on professionally design drawings done in
illustrator all the time -- using forms, views, pages, etc.. all available in
version 7.

I'm not advocating dropping XPages. I'm advocating freeing the IDE used for
them from the burden of the rest of the kit, and letting it grow at its own
pace.

I don't agree that this would move DDE into maintenance mode -- but if it did,
but that resulted in a better XPages IDE, we'd still be better off. Let's face
it John, right now large parts of DDE are already in Maintenance mode.
re: Fixing Domino Designer - By John Head on 06/15/2010 at 03:43 PM EDT
I see what you mean there Andrew - but I think reality is XPages will get the
integration with things like the Vulcan mindset vs working on the other design
elements.

Sometimes I think the biggest weakness of the N/D platform is it's adherence to
backwards compatibility. It is also one of it's greatest strengths.
re: Fixing Domino Designer - By Andrew Pollack on 06/15/2010 at 03:52 PM EDT
Backward -- even "bugward" as Maureen puts it -- compatibility has served the
product line well, and enabled the upgrade process to go much faster. I think,
however, that there's room for a reasonable deprication process as well. The
alternative as atrophy and that's not good either.
re: Fixing Domino Designer - By Erik Brooks on 06/15/2010 at 01:50 PM EDT
Good point. What if there was simply an option when you install DDE for "full"
and "modern only"?

The first could be DDE as it exists today.

The second could be just the "modern" features I proposed below.
re: Fixing Domino Designer - By Tim Tripcony on 06/15/2010 at 04:02 PM EDT
I dig Erik's suggestion... this is Eclipse, after all, is it not? Ought we not
be able to install a "base" Designer, then install additional plugins if we
want additional features? Some of us are doing that already, it's just that
we're adding those additional plugins on top of something that's a bit bloated
and cumbersome to begin with.
re: Fixing Domino Designer - By Dan Frederiksen on 06/18/2010 at 10:23 AM EDT
I was thinking along these lines as well... when I open a database in Designer
I should only the types of design elements being used in that application (in
the right hand column navigator) or at least provide an option to hide the
design element sections not being used... that would clean things up quite a
bit for each specific application I'm working on whether legacy or xpages. If I
want to add xpages, forms, agents, etc. I can add them each as a "plugin". If
only the design of designer itself was exposed... I'd love to see what people
could do designing "skins" for it.
re: Fixing Domino Designer - By Karl-Henry Martinsson on 06/15/2010 at 02:22 PM EDT
John,

I am just saying that it probably would take ME a week, because I don't know
XPages. I have 14 years of Notes development experience, and can do stuff nice
and fast in regular Designer.
re: Fixing Domino Designer - By Erik Brooks on 06/15/2010 at 01:22 PM EDT
I've thought for awhile now that a standalone XPages dev environment would be
good. Particularly with respect to the younger/college crowd.

Include XPages, Java, SSJS, Agents, and Views. Don't mention the thick client
at all -- make everything browser-based.

From there it's *almost* a slam-dunk. Your only real issues for new-developer
uptake become:
- agents can't run SSJS
- you need to know @Formulas for views
- no "offline"/local functionality for XPage delivery
re: Fixing Domino Designer - By Peter Presnell on 06/15/2010 at 03:11 PM EDT
Perhaps the only thing missing is SSJS for agents. It would be inconsistent to
have LS for agents when almost everything else for Xpages (server sided) is
SSJS. of course we have that inconsistecy now, but having two Designers would
just make it more obvious.
re: Fixing Domino Designer - By Tim Tripcony on 06/15/2010 at 04:10 PM EDT
Amen. Like others have mentioned (here and elsewhere) it makes no sense to
refactor an agent from LotusScript to Java unless the agent suddenly needs to
do something that LotusScript simply can't do (or can't do well). SSJS already
has a "UI-less" context - it doesn't have the window object that client-side JS
does, and doesn't suffer from the nightmare that is the DOM API - so it would
be a perfect fit for background tasks... and, if IBM can find a way for SSJS
agents to run within the same JVM as XPages, we'd get enormous performance
benefits - not only because of optional techniques like scope variables, but
because SSJS just runs so much faster than equivalent operations in
LotusScript/Java agents.
re: Fixing Domino Designer - By Wayne on 06/15/2010 at 01:41 PM EDT
I second that motion...
Can't wait to see which modern features should be added.
re: Fixing Domino Designer - By bruce lill on 06/15/2010 at 07:23 PM EDT
I have built web sites with Notes that do everything that XPages does but for
me it's less effort, mostly because I've done it for years. I'm currently
writing the class material for Domino development (XPages & Forms) and can see
where these should be 2 products. Having the ability to just build a view and
basic form would be all that XPage DE would need. Since the LS editor for
agents and libraries is over there, it could be left in the XDE. The next step
would be a thin client that only runs XPages and replication for local apps.

First IBM has to admit to the world that it's a development environment and
not just mail.
re: Fixing Domino Designer - By Simon O'Doherty on 06/16/2010 at 07:59 AM EDT
Have you thought about posting these to IdeaJam?
re: Fixing Domino Designer - By Dwight Wilbanks on 06/17/2010 at 12:38 PM EDT
I'm tired.

We do this exercise fairly frequently, when there is some glimmer of hope that
IBM might actually listen to us.

How bout some low hanging fruit. IBM absolutely refuses to give us a class
editor in basic client for lotusscript, how about opening up API handles in the
designer so that a business partner can do it.

What can we name that is significantly different in the HTML rendering since
version 4.5 ish? If forget exactly when it went from flat HTML files to the
http task. I know that HTML rendering has nothing to do with the designer
client, but, it contributes to the finished product. They would not have to
implement a full blown CSS system to see that when cell property is selected on
a table that directly maps to and HTML property, that they should render it
that way.

The question could be asked, why do they ask us for HTML row attributes then
ignore them, they could solve the issue by removing the entry fields on the
table properties, OR they could add it to the HTML rendering engine.

Like I said, I'm tired, I still develop in Lotus Notes because of the Golden
handcuffs, as soon as I can get my other skills to a livable degree, I will be
leaving the platform too. Yes, IBM is reading, but they are not listening.


Other Recent Stories...

  1. 09/04/2018With two big projects on hold, I suddenly find myself very available for new short and long term projects. In twenty five years, I don't think I've ever written an entry like this, but if you need the kind of work I do now would be a great time to get in touch. Both of the big projects I had lined up for late summer and early fall have been placed on hold and will be that way for a while. With the kids now all off at college and careers, I'm open to more travel than such than I have been in decades, but unless something else comes along, I'll be here working on updates to Second Signal and other things that ...... 
  2. 07/13/2018Who is HCL and why is it a good thing that they are now the ones behind Notes and Domino?We need to address some biases here. IBM has made a deal under which the Notes & Domino software and intellectual property is now being developed and maintained by HCL America. HCL America is part of the very large "HCL Technologies" company that has grown from its roots in India to become an 8 Billion Dollar company with a global presence in the IT Industry. You could be excused for initially believing, as many people do when they hear this, that "they've outsourced the code to India where they'll milk it ...... 
  3. 03/21/2018Domino Apps on IOS is a Game Changer. Quit holding back.BOOM. This will be as important for the platform as Traveler. If your company has ditched Notes and Domino, I feel sorry for you. For companies that do use Notes/Domino this is a game changer and Apple should be paying attention. Here's why: There are hundreds of little Notes client applications you'd never spend the time and money to build and deploy for your internal user base on IOS that we use Notes for all the time (those of us still using it). Now, those are suddenly ALL available on the iPad. ...... 
  4. 02/15/2018Andrew’s Proposed Gun Laws 
  5. 05/05/2016Is the growing social-sourced economy the modern back door into socialism? 
  6. 04/20/2016Want to be whitelisted? Here are some sensible rules for web site advertising 
  7. 12/30/2015Fantastic new series on Syfy called “The Expanse” – for people who love traditional science fiction 
  8. 10/20/2015My suggestion is to stay away from PayAnywhere(dot)com  
  9. 08/07/2015Here is one for you VMWARE gurus - particularly if you run ESXi without fancy drive arrays 
  10. 08/06/2015The Killer of Orphans (Orphan Documents) 
Click here for more articles.....


pen icon Comment Entry
Subject
Your Name
Homepage
*Your Email
* Your email address is required, but not displayed.
 
Your thoughts....
 
Remember Me  

Please wait while your document is saved.