8.5 Designer For Notes Client Development Is A Net Negative

HCL Domino Domino Forum
1

After the disappointment of finding that there is no Eclipse LotusScript Editor it took me a while before I could motivate myself to take a serious look at Domino Designer 8.5. I would like to be more positive about this release but it is shaping as a major disappointment.

I have been developing Notes applications for 15+ years. During that time 80-90% of my work has been developing applications for use with the Notes Client. As a result, these comments relate specically to that aspect of what I would consider as “Core” Notes development.

This release will be significant for several reasons:-

  1. For the first time design elements are being added that are NOT supported on the Notes Client

  2. This release will probably be the first where developers of Notes client applications are actually worse off.

On the positive side I can see where the Eclipse environment is going to be HUGE for development. The new Outline, Properties, and Component panels provide me with a lot more information about my design elements and provides additonal tools that will make me more productive. I also love the ability to switch between design and code perspectives.

The problem is that these features appear to only be available for the two new design elements (X-Pages and Custom Controls)and these are for Web client development ONLY. For the other 90% of design elements (100% of the Notes client design elements) I am left with what looks and feels like a hack to place what I already had with a non-eclipse Designer in the eclipse environment. I very much doubt the Notes 8 client would have been allowed out the door looking like this so I wonder why IBM are considering letting Domino Designer be released in this sort of a state.

When I step back and look at it, as a developer of Notes client applications, I would consider myself to be worse off if I were to migrate to 8.5 than remain with an earlier release of Notes:-

  1. There doesn’t appear to any significant enhancements for either the IDE or programming functionality. (Sorry, but setting the system date/time and a few NotesDOcumentCollection methods does almost nothing). So even if all the bugs with the Eclipse port can be found and fixed, at the very best I will be left with nothing more than what I already have.

  2. I now have an outline, properties, and control panel eating up screen real-estate and offering absolutely nothing for Notes client design elements. So I know have to close these all down so that I can get back the space I need.

  3. This is still a beta so I am sure improvements will be made to performance, but I doubt that the Eclipse IDE is ever going to run faster that the existing IDE.

  4. I now have to find my design elements in a new heierarchy (especially the database icon). This is a pain I would usually accept if I was getting something in return, but I’m not.

  5. It seems we now have new naming standards for design elements such as XPages and Custom controls.

  6. By offering design elements with work in the be client and not the Notes client it is even harder for me to build applications that support both clients with a consistent UI and functionality. Users never understand that, they just exect their application to work the same!

In short, I get no additional functionality, the likelihood of new bugs, in a slower environment, and with less screen real estate to work. So the value proposition of this is…?

Suggestions:

  1. If we are going to have design elements that work in one environment and not the other, provide an attribute at the Application level where I can designate if the application will be accessed by Note client and/or Web client. Then automatically hide the design elements that are not relevant.

  2. With the number of design elements growing, give me the ability to nominate the design element types I plan to use for the application so the options available can be reduced (e.g. I rarely have Java Resources, Navigators)

  3. Automatically close the new Outline, Properties, and Control panels when the design element does not support them.

In the past I have had to push the organizations for whom I work to upgrade to newer versions of Notes so that I can get access to the latest development capabilities. This has been difficult because such decisions are tied to the deployment of the Notes client across the organization. Unfortuantely, with this release I will be doing the opposite. I will actually be campaigning to stop this release from being deployed for the client I work for because (as I see it) I am actually worse off. I am still hopeful that another release will come out that addresses the needs of Notes client developers, but this is NOT that release.

2

Subject: I couldn’t agree more really

I see this as a major dropped ball for the Designer. But for me, mostly from the Java perspective.

  1. No Java Editor

This beggars belief. Eclipse has one of the nicest Java editors I have ever come across. When porting the designer to Eclipse, this should have been one of the very highest priority improvements. Currently the Java editor in Notes is the single worst Java development IDE in existence. That sounds extreme, but barring Notepad, nobody would produce such a bag of rubbish and have the presumption to call it a Java IDE. We have lived with this appalling editor for years, and now we have Eclipse?.. Still no editor

  1. Still no UI classes in Java.

Nuff said.

Then as the OP points out

  1. No updated LS editor.

This doesnt bother me so much as the LS IDE as is, is way ahead of the Java one.

  1. No improvement in HTML production.

We NEED the Forms and Page designers to use STYLES. Death to the FONT tag. I realise it is virtually impossible to go back and improve the HTML translation for existing forms/pages. BUT if you gave us a true native STYLE element, that we could use going forward, then Lotus could start to produce decent style based HTML.

Instead we get thrown a bone from the dreadful bloated world of JSF. I have used JSF from within Websphere and the thought of it following me into the Notes world fills me with a sense of deep foreboding. Prepare yourselves for the world of incomprehensible stack traces, as layer upon layer of abstraction blow their collective stacks.

These Xpages allow nothing more than Ajax developers armed with prototype.js have been achieving for years. I’m sure they are kinda nice to use, and I’m coming across very negative about them, but I don’t NEED them.

What we NEED is for IBM to update the >> core bread and butter functionality << in the Designer to something that isn’t an embarrassment to the entire Notes community.

Oh and we get ANOTHER scripting language! Yay!

P.S. I quite like the XPages but we needed another design element and another scripting language like we needed a hole in the head.

Simon

3

Subject: Spot on!

I am so sick and tired of hacking out friggin tags from my generated code. Its 2008 not 1998. I highly recommend the Notes Designer dev team read some background on CSS design. Go look at http://www.csszengarden.com. Get the book “the Zen of CSS Design”. This will really change how you think about UI design.

I expected a new editor for forms and views in Eclipse. The event view is not associated with the form/view elements.

I don’t know about anyone else, but XPages just does not excite me. If I want JSF, I’ll write a Java app and deploy to WAS. I’ll get better editors in RAD. At the very least I can then use version control on my design elements.

This should be the priorities:

  1. New LotusScript editor with content assist (ctrl+space)

  2. Forms / views tied to the Eclipse editors

  3. Utilize the Eclipse Java editor for the Notes designer Java code.

  4. Updated HTML rendering engine that produces style and/or span elements rather than deprecated HTML elements(font, b, i, etc).

  5. Ability to hook into a version control system ala Subversion or ClearCase. After 15 years of coding in Domino, I’m still relying on file system copies rather than true atomic versioning with branching/merging.

  6. Tie in the Eclipse CSS editor.

  7. Ability to see the outline of your LotusScript code (like in Java) for your custom Java classes.

  8. Integrated LotusScript debugger.

I could think of more, but its Saturday and the family needs attention.

4

Subject: Enhance the existing functionality!

Simon: “update the >> core bread and butter functionality <<”

Yes, yes, yes and yes!!!

Why bring us all the new things, which are usable only for some developers of Domino Web applications, instead of doing some “homework” to fix broken features, making them finally usable. DXL round-trip anyone?

The answer is simple, but I don’t like it: because new features sell better then corrected ones.

Simon: “We NEED the Forms and Page designers to use STYLES.”

Same thing. Enhancements to existing features…

Simon: “Still no UI classes in Java.”

This would be great, really great!

In my opinion, a lot of enhancements for LotusScript would be even better (because of the bigger codebase)! Subclasses from product classes, overloading methods, concurrency, interfaces, etc. Have a look at IdeaJam and look for the OOP tag…

Maureen: “The LotusScript editor remains a high priority to release as soon as we can. … as soon as possible.”

In my honest opinion, everything after 8.5 is too late. Why is this so difficult? Why do you have not enough resources for this part? Priorities? Wrong priorities in my opinion! This would be something EVERY Notes/Domino developer would get a real benefit from.

Maureen: “The Notes client does use JavaScript libraries and does have some support for style sheets”

Did you extend the JavaScript functionality in the Notes client? I haven’t seen too much advantages versus the formula language so far, but some limitations.

Did you improve the CSS functionality in the Notes client? The current implementation lacks a lot. First C in CSS = cascading?! CSS selectors?! CSS 2.0?!

Without this, the new editors are good for Domino Web application developers, but for Notes application developers?

Maureen: “Search”

great!

Maureen: “in 8.5, xpages and custom controls are web only, but Notes client support is under serious and active investigation.”

Investigation??? Ouch! Not under serious and active development?! So we MAY await them in version 9 or never?

When Bob Balaban stated, “We want to make Lotus Notes/Domino a kick-ass development platform, again”, I hoped to get a kick-ass development platform for NOTES applications, not only Domino Web applications. I am seriously disappointed.

Thomas Bahn

5

Subject: a number of comments…

  • The LotusScript editor remains a high priority to release as soon as we can. I share your disappointment that we couldn’t finish this for 8.5, but we will get it to you as soon as possible.

  • the Java editor work also continues, and will also ship as soon as possible. Obviously we don’t need to write the actual editor for Java, but we do need to integrate it with the Notes model of each Java agent and Java script library being a project until itself. Eclipse doesn’t support nested projects. We have a solution, and development proceeds on it…

  • The Notes client does use JavaScript libraries and does have some support for style sheets - both these elements have new Eclipse based editors in 8.5.

  • If you go to Window - Preferences, you will see on the first page of Domino Designer preferences an option to automatically minimize the various Eclipse view parts (properties, events, etc) when editing elements such as forms which don’t use them.

  • try comparing two forms to each other, a Search across your workspace or each project (nsf). These Eclipse functions add value regardless of whether you are developing for the client or the web.

  • in 8.5, xpages and custom controls are web only, but Notes client support is under serious and active investigation.

8.5 is the beginning of a new journey for Designer. It’s true that there is more to do, but we are committed to making the Designer well worth your while.

6

Subject: Additional Comments Re Excess Panels

Hi Mauren, I tried as you suggested to set the Designer preferences to minimize selected panels. This only minimizes the panels leaving approx 1" consumed on the right and panel headers using lesser space below. When I swicth between design elements the panels expand/collapse depending on the type of design element.

I can close the panels completely, but then when I switch from legacy design elements to X-Pages the panels I now need remain closed. I expect even with a new application I will still be creating views, outlines, framesets etc. so I would be driven crazy opening and closing these panels as I switch between design elements.

If we could somehow change the behavious of closed panels to behave like minimized panels the frustration would go. e.g If Designer Preferences instead specified closing panels for legacy design elements and this taggled off/on when switching between panels. Or simply the current state of closed panels is preserved for legacy design lements as a group and the new design elements as a separate group.

7

Subject: A couple of tips about the panels in Eclipse

  1. You can double-click on a panel header to switch between windowed and full-screen. This lets you open the form editor, for example, as it used to be in 7, without the surrounding views.

  2. You can save a perspective (a collection of view settings) and switch between perspectives. However I don’t know how you can link this to a toolbar icon to make it one-click which would make it much easier

I would like to see the traditional Notes editors configured by default as one perspective, and the new ones as a different perspective, with DDE automatically switching between them.

8

Subject: Not Just LotusScript Editor

Thanks for your response Maureen. The tip on closing those other panels via preferences goes a long way towards solving one of my concerns.

Whilst I agree the eclipse LotusScript editor (and for java developers) the eclipse Java should be priorities. I am just as interested in seeing eclipse versions of a Form, Page, and View editor. I think what has been done with the X-Pages editor is great and I cannot wait until I can do a similar thing with a Notes form. e.g. drag/drop controls from the control panel, create custom controls, see an outline of the form in the outline panel, view the form as code, and get all those properties into the eclipse panel. You people have done a great job and are definitely on the right track. I would definitely vote to have you given a lot more resources to get this all done sooner rather than later. Because, when we have eclipse editors for all the Notes design elements AND a Note client implementation of XPages we will be pretty close to achieving Bob Babalon’s goal of creating a “kick arse” development platform. (Well maybe we need to give the LotusScript language a facelift too).

9

Subject: If …

XPages works in the Notes client, why do you need an updated Form and View editor? Personally, if they solved the XPages in the client problem (which they will, just a matter of when vs if) and add a few more features, the form and view editor can stay. XPages can be the way we build apps going forward, and only write things once. The things I think we can do in XPages in Notes will be amazing …

Yes, it is radical. yes, it is a big change. But it might be best for all of us long term. Imagine being able to write apps for web and client once … and truely once. And getting full css and js support in the client. XPages should do that.

10

Subject: and …

have you looked at what you can do with an XPage Column Header and Data … click the blue diamond … once that works in the Notes client, it just changed Notes View development forever