Andrew Pollack's Blog
Technology, Family, Entertainment, Politics, and Random Noise| Professional Services | Second Signal | Presentations | Andrew's Blog | Support |
Fixing Domino Designer -
By Andrew Pollack on 06/15/2010 at 11:47 AM EDTI’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.
re: Fixing Domino Designer - By Darren Duke on 06/15/2010 at 11:56 AM EDT
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.
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.
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.
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".
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.
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."
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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...
- 01/26/2023Better Running VirtualBox or VMWARE Virtual Machines on Windows 10+ Forgive me, Reader, for I have sinned. I has been nearly 3 years since my last blog entry. The truth is, I haven't had much to say that was worthy of more than a basic social media post -- until today. For my current work, I was assigned a new laptop. It's a real powerhouse machine with 14 processor cores and 64 gigs of ram. It should be perfect for running my development environment in a virtual machine, but it wasn't. VirtualBox was barely starting, and no matter how many features I turned off, it could ......
- 04/04/2020How many Ventilators for the price of those tanks the Pentagon didn't even want?This goes WAY beyond Trump or Obama. This is decades of poor planning and poor use of funds. Certainly it should have been addressed in the Trump, Obama, Bush, Clinton, Bush, and Reagan administrations -- all of which were well aware of the implications of a pandemic. I want a military prepared to help us, not just hurt other people. As an American I expect that with the ridiculous funding of our military might, we are prepared for damn near everything. Not just killing people and breaking things, but ......
- 01/28/2020Copyright Troll WarningThere's a copyright troll firm that has automated reverse-image searches and goes around looking for any posted images that they can make a quick copyright claim on. This is not quite a scam because it's technically legal, but it's run very much like a scam. This company works with a few "clients" that have vast repositories of copyrighted images. The trolls do a reverse web search on those images looking for hits. When they find one on a site that looks like someone they can scare, they work it like ......
- 03/26/2019Undestanding how OAUTH scopes will bring the concept of APPS to your Domino server
- 02/05/2019Toro Yard Equipment - Not really a premium brand as far as I am concerned
- 10/08/2018Will you be at the NYC Launch Event for HCL Domino v10 -- Find me!
- 09/04/2018With two big projects on hold, I suddenly find myself very available for new short and long term projects.
- 07/13/2018Who is HCL and why is it a good thing that they are now the ones behind Notes and Domino?
- 03/21/2018Domino Apps on IOS is a Game Changer. Quit holding back.
- 02/15/2018Andrew’s Proposed Gun Laws
3) and the 32K and 64K limits on stuff.....