Beyond The Yellow Bubble

In my last blog, I made mention fo the many new features being considered for addition to the coming releases of Lotus Notes.  Amongst all the material listed it may not have been obvious the extent to which IBM have announced plans for extending the LotusScript language.  So for those of you who are LotusScriot developers, the following is a complete list of all the enhancements for lotusScript that I have heard announced so far:-

-- End Of List

I think there might be a hint there for those of you that have not yet made the bold step into XPage development ;)

Function IIf(Condition As Boolean,TrueResult As Variant,FalseResult As Variant) As Variant
Try:
 On Error Goto Catch
 If (Condition) Then
  If Isobject(TrueResult) Then Set IIF = TrueResult Else IIF = TrueResult
 Else
  If Isobject(FalseResult) Then Set IIF = FalseResult Else IIF = FalseResult
 End If
 Exit Function
Catch:
 Stop
 ReportError Nothing
 Exit Function
 
End Function

Try:
 On Error Goto Catch
 Set Body = Source.Document.GetFirstItem("Body")
 Filename$ = atfTempDir() + "\attachment.doc"
 Forall o In Body.EmbeddedObjects
  If (o.Type = EMBED_ATTACHMENT) Then
   Call o.ExtractFIle(FileName$)
   Call Source.Import("Microsoft Word",FileName$)
  End If
 End Forall
 Call Source.Save()
 Exit Sub
Catch:
 Stop
 Exit Sub

Over the years I have given a lot of thought to programming languages, especially as they relate to Lotus Notes development.  I blog about it a lot.  Yes Nathan I'm hitting them all over the head with a stick again....  I have expressed my frustration at the lack of development of the LotusScript language that is core to so many Notes applications.  I have wondered about the lack of penetration of Java into the Notes development world.  And lately I have been asking the question why SSJS and do we need yet another programming language in Notes?    So just what is the best programming language for Notes?
:
The Case For LotusScript
Some may view me as something of a LotusScript biggot.  I love the language and what it allows me to do with Notes.  Basic was the first language I ever used.  It was so easy to understand I taught myself by simply reading other people's code and experimenting.  There was a time when LotusScript was more advanced than Microsoft's VBA but now it has fallen lightyears behind VB.Net.  It is popular in Notes because so many people find it (relatively) easy to learn.  It is popular because it can be used almost anywhere inside Notes applications (except View selection formulae, hide-when formulae and a few other spots).  It is popular because so many applications are already built with LotusScript as its core.  And finally with 8.5.1 we have a half-decent editor for LotusScript.
:
The Case For Java
In many ways Java is a superior language to LotusScript.  It provides vastly superior support for Object Oriented Programming.  It comes with an extensive library (framework).  It is also one of the most popular programming languages.  Two of the things that have been attributed to holding back Java in Notes (access to Notes UI classes and a decent editor) have both been provided in 8.5.1.  And yet.....  despite all this I do not expect to see a significant momentum towards Java anytime soon (outside of Eclipse, Expeditor, Plug-In development etc.).
:
The Case For Server Sided JavaScript
This is a completely new language, so why bother given I have all my existing code is in LotusScript, Java, @Commands (or a combination of all three)?  Well for one thing it is presently the only language supported directly by XPages.  There are ways to execute Java code and even more obscure ways to execute LotusScript code but I don't see these being very practical.  So if you wish to develop Xpages you have little choice.  And if you don't wish to develop with XPages you have little chance to use SSJS at the moment either!   One of the key reasons to consider SSJS  is that this seems to be where IBM is investing most of its time and effort on program language development for the forseeable future.  But perhaps the most compelling reason (at least for me) is that when all things are said and done SSJS is probably the best match for Lotus Notes than any of the other programming language choices.
:
Yes you did read that right.  The LotusScript flunkie is actually suggesting SSJS may be a better fit for Notes development than his beloved LotusScript.  I have done a lot of SSJS programming over the past six weeks and the more I use it the more I like it.  I have begun to realize the complexity in using SSJS is not with the SSJS language itself but rather learning to understand the complexities of Xpages. SSJS is not vastly different to LotusScript but it allows me to do things I could only dream about with LS.  There are still areas left for improvement but if IBM are focusing on this language there is more chance these will be fixed than any of the 100+ ideas for LS posted on IdeaJam.
:
One of the key reasons I like JavaScript so much is that it is built on objects (and remember I am an OOP).  Until recently I thought it was a weakness that JavaScript was so loosely typed.  Now this seems to be such an asset.  And this seems to fit in so well with whole Notes concept.  Documents as a collection of fields that may or may not be present in any one document and may or may not be of the same data type in every document.  Documents copied and pasted en-mass from one database to another (when allowed).  Views that may contain a collection of doccuments of different types whose only association may be they share a few fields with the same name (if at all).  And yes, love it or hate it there are none of those foreign key constraints that stop me adding whatever document I want to my database.  And replicas of each database created just about everywhere just in case... In an ordered world of tightly defined tables with fixed columns, column types, key constraints and nullable fields a tightly structured language such as Java makes perfect sense.  And C# with its interfaces, sealed classes, abstract classes, partial classes etc. is well suited to projects with 10+ developers.  In the unstructured world of almost anything goes just get the application out the door as quickly as you can  Mr/Ms. sole developer, multi-tasking Notes programmer -- a language such as SSJS seems to be an almost perfect fit.  And not just for the minority of us who write OOP with Notes.  For procedural programmers we have the nifty ability to invoke many of the @Functions as a standard part of SJS language.  The bous for SSJS is that it shares the basic syntax with JavaScript, the dominant language for Web client programming.  So after a while you get used to placing those braces around all your compound statements and you remember that different casing means a different variable/functions.
:
 To put it simply, there is a reason we have many programming languages.  Each has its own style.  Each its own strengths (and weaknesses).  The style I see in SSJS seems a very natural fit for Notes and a great many (but certainly not all) of the developers who are attracted to Notes.
:
Of course it is not a clear cut as switching from one language to another.  We still have all those legacy apps to maintain.  And there is no sign of SSJS being supported in any of the Notes Classic design elements or even agents real soon.  So that leaves XPages, and the rub with that is for the Notes client, XPages really does not (yet) offer much outside of a glorified embedded browser (I can see the hate mail on this already!)....  But that is today.  IBM have already indicated that they plan to extend XPages to provide Notes client control.  When they do, that opens up the chances of doing some Notes client development with SSJS.  And hopfeully some time soon we will get some sort of clear indication whether or not IBM plan to provide a single programming language that can be used anywhere across the product.  Because as much as I now appreciate SSJS I still see little value in investing too much effort into it outside of Web Client or (possibly) dual client applications.  Until I can build the majority of my apps with XPages alone or SSJS is supported in all the design elements I need, it is difficult to find a compelling reason to consider using two programming languages (plus some @Commands here and there).  So the challenge is very much there for IBM so make some sense with the programming languages it supports.  Can IBM afford to let LotusScript slowly die before it has established a viable alternative?  Do LotusScript and Notes classic design elements need an extension to make them more like SSJS & XPages to tide us over until the transition is complete?  Is it OK that I like hot-dogs without mustard but would still kill for a meat pie with sauce.....
:
Related Posts
Programming Language - Does It Matter?
LotusScript v JavaScript
Does LotusScript Have A Future
LotusScript Revamp (20 Things I'd Like To See)

As many of you many know I have been lucky enough to have the chance to participate in the OpenNTF project to extend the Discussion template.  The team includes Niklas Heidloff and Steve Castledine, two of IBM's great application developers.  These guys are constantly coming up with great ideas for this project.  One of Niklas's contributions was the idea of using video as a medium to communicate some of the ideas we have for the template.  Thanks to Niklas it is now occurring to me that video may be one of the missing pieces for one of my other OpenNTF projects, the .Domino Framework.

Here is my first video which explains one of the framework's developer tools, the Property Generator and how it can be used in conjunction with the new Eclipse LotusScript Editor to quikcly generate LotusScript classes.  So if you haven't yet had a chance to see the new LotusScript editor up close, here's your chance.

Disclaimer: IBM Lotus Notes/Domino and Lotus Notes Traveler 8.5.1 is prerelease code and there are no guarantees from IBM that the functionality presented or discussed will be in the final shipping product.
YES FELLOW LOTUSSCRIPT DEVOTEES - THE WAIT IS ALMOST OVER!!!

If you are like me and you write lots of LotusScript code you have probably been waiting for a new LotusScript editor more than anything else.  With 8.5.1 that long awaited dream comes true.

Note: If you are most unlike me and write lots of Java code then you long awaited Java editor is also here but I will leave that for someone better qualified than I to blog about....

The extent to which this new tool will make a difference to you life will largely depend on the style of LotusScript code you write.

Object Oriented Programmers (OOP), like me, write almost all their code as classes inside placed in the Declarations module of LotusScript Libraries.  As much as 98% of our LS code can be contained in these LS libraries.  We have our own weird language with terms like base classes, properties, methods, constructors, event handlers and delegates.  It is this style of LS coding that will benefit the most from the new DDE LS Editor.

Procedural Programmers strive to build reuseable code using functions and subroutines that are typically stored in LotusScript libraries and/or agents.  You too will benefit from the DDE LS Editor but not to the same extent.

The third style of LS coding is what I call spaghetti coding.  Here the focus is placing code directly in the various events for forms, views, fields, actions etc.  Code re usability usually consists of copy/paste from one event to another.  This is perhaps the most common style of LS coding and the style that will benefit the least from the new editor.  If you code this way almost none of your code is in LS Libraries and the only time you are likley to make use of the new DDE LS Editor is when you code LS Agents.

Class Editor
For OOP this is a HUGE productivity saver...  Some of the LS Libraries in the .Domino Framework have 5,000+ lines of LS code.  Prior to 8.5.1 this meant navigating through 5,000+ lines in a single Declarations module.  With the new class editor the outline for my library is broken into classes and then into properties and methods (Subs, functions).  All the code for each class is shown as a single text stream.  They properties/methods are all shown in alphabetical order, regardless of the order they were written.  This can be a plus to some and a minus to others.  Personally I like it although I would prefer properties are shown first before methods.  Color, icons etc are used to convey information such as private versus public, property versus method.  Clicking on an entry causes the editor to jump to the declaration for that code element and it is highlighted.

Warning: It was previously possible to declare constatnt in the Options section.  If you (like me) did this to get at least some of your code out of the declarations section, the DDE LS Editor willmove the constants from Options into Declarations but leave any comment statements behind.  It is best to use a non DDE editor to move the constants with the comments manually into Declarations so the comments dont get jumbeled.

Error Reporting
All LS coders get the benefit of the improve LS error handling.  Now you no longer need to do a save before finding out if you have errors in your code.  Nor do you have to manually find each and every line reporting an error.  As you complete statements the DDE LS Editor places a red line next to each line with an error.  You also have the option to save you LS code even if it has errors.   complete list of error is shown in an Errors panel that can even be detached and moved to another monitor for your viewing pleasure (especially if your list is as long as mine gets sometimes!)

Class Definitions
The next killer OOP feature is that the new editor recognizes custom classes.  Hover over any declaration and a definition of the datatype or class will appear as a tool tip.  If its a custom class it displays information about that class.  Press F3 and the editor will take you to the definition of that class.


Template & Comment Templates
This was a feature I had not been expecting so it was a nice surprise.  Notes Preferences now has a section under Domino Designer for LotusScript Editor.  In there you can define templates of commonly used code that can be quickly inserted into your code.  Comment Template allow you to define documentation for each type of code module that is then automatically inserted each time you create a new module (class, sub, property get etc.).  There are a whole host of parameters that can be specified to get the date, developer name, module name etc. inserted in a specific way.  I use the LotusScript.Doc standard for comments so now I have an easy way to have this style added automatically to my code saving me heaps of time on one very important, but very dull, task.

Other Goodies
There are other useful feature...

1. The ability to auto indent your code
2. The ability to manually indet entire blocks of code
3. The ability to turn a line of code into a comment (and undo) via <Ctrl></>
4. Goto Line <Ctrl><L>

Verdict
This is version 1.0.0 of the DDE LS Editor.  It is nowhere near as sophisticated as the editor I used for C# (Visual Studio) but it is a great start.  It is almost guaranteed to make every LotusScript programmer smile.  I was surprised it was developed as an Eclipse component as so far it is the only component of Classic Notes that IBM have shown any signs of migrating to Eclipse.  I am hoping this may mean that IBM have plans to use LotusScript in the future for its new wave of design elements (Xpages) or at least are keeping the door open for such a possibility.  Whatever the logic I am very thankful that this tool is finally available and simply cant wait until I can use it on a daily basis.  Thanks IBM.....

Unfortunately I did not wake up in time for this morning LotusKnows Jam bloggers call.  For me 5am meetings can be something of a challenge!  So despite missing the call I felt compelled to at least add something on the topic.  So how about my top 10 LotusScript Knows...

1) LotusScript knows that not everyone wants to program in Java.
2) LotusScript knows how to exploit the power of the Notes client
3) LotusScript knows it is now under attack from JavaScript
4) LotusScript knows the meaning of the word patience when waiting for its new editor
5) LotusScript knows how to take out the garbage without being told
6) LotusScript knows how to talk with Forms, Views, Folders, Outlines, Agents, Framesets, and Pages
7) LotusScript still knows how to talk with all versions of Notes from 4.0 to Notes 8.5
8) LotusScript knows how to follow the same instructions on both the client and server
9) LotusScript knows it is still the favorite programming language of Notes developers
10) LotusScript knows its full potential is still to be realized

I have been having lots of fun the past 3 weeks using Domino Design 8.5.0.  There are LOTS of issues.  There is one in particular I would like to bring to the attention of Notes Developers who use LotusScript heavily and have already or will soon migrate to 8.5.0.

It seems in the world of Eclipse the NotesUIWorkspace class no longer be relied upon in the same way it  could in the past.  In particular the CurrentView and CurrentDocument properties of this class can be totally unpredictable.  When you use the Notes 8.5 client (especially with Designer running) you will often see the screen flicker, move around, or randomly switch between the Designer client and the Notes client.  I have even seen a minimized Designer client reappear on the screen for no apparent reason.  Yes, my client is officially haunted!!  I am guessing this relates to the way the Notes client interacts with Eclipse and that certain background tasks trigger parts of the clents temporarily gaining focus.  If this occurs at the same time as a piece of LotusScript code is using NotesUIWorkspace to gain access to the current view or document then you might end up with nothing, or a reference to something totally unexpected.  These errors are random and very hard to reproduce.  An application will test occy 99 times and then fail the 100th time with the same test script.

If you have the LotusScript debugger running it gets much worse.  The debugger seems to make the NotesUIWorkspace lose all sense of where it was at the time the LS code was invoked.  e.g. LotusScript code inside a view action whose first line of code is Dim UIW as New NotesUIWorkspace now has no knowledge of the CurrentView.

The end result of all this is that code that runs without the LS debugger running no longer runs when the debbugger is running.  So if you are trying to debug LS code you may find your code breaks well before you get to the bit you are debugging.

The only workaround I have found so far is to try and redesign the code in a way that information about the current NotesUIView or NotuesUIDocument are stored in a variable that is global to the form or view as part of a QueryOpen or similar event that passes in a reference to the source object.  This may not always be possible.  In that case you may find yourself like me reverting back to print and dialogbox statements as a very primitive alternative to the LS debugger.

It's been a while since I shared some code....

The DominoMemo class was developed as a way of simplifying the code an application requires to produce e-mail notifications. The 1.0.2 version of .Domino Framework will contain a new AppendViewAsTable method that allows an application dveeloper to request a table be added to the body of a memo that shows the data in the view along with doclinks to each document.  This is similar to the Copy Selected as Table command and NotesNewsletter class.  The method also allows the data embedded to be restricted to a single category in the view.  The code is provided below for those that wish to adapt it for their specific needs.

 '/**
 ' *  Append the data in a views as a table in the body of the e-mail
 ' * 
 ' * @param View    The view to be appended
 ' * @param Category  Single category of view to be included - Nothing = all rows
 ' */ 
 Sub AppendViewAsTable(View As NotesView, Category As Variant)
  Dim Column    As NotesViewColumn     ' Specific column in view
  Dim ColumnIndex  As Integer          ' Index of the column being processed
  Dim Doc     As NotesDocument
  Dim TableColumn As Integer
  Dim DocEntry   As NotesViewEntry       ' View entry for column being processed
  Dim NoColumns  As Integer
  Dim RowIndex   As Integer          ' Row in table being processed
  Dim RTNav    As NotesRichTextNavigator    ' Allows navigation within Rich Text Item containing table
  Dim TableStyle   As NotesRichTextParagraphStyle
  Dim TableStyles()  As NotesRichTextParagraphStyle ' Styles used to format table
  Dim ViewNav   As NotesViewNavigator     ' Navigation of view
  Dim ViewEntries  As NotesViewEntryCollection   ' Entries in view
Try:
  On Error Goto Catch
  Redim TableStyles(0)
  Set TableStyles(0) = Session.CreateRichTextParagraphStyle()
  TableStyles(0).LeftMargin = 0
  TableStyles(0).FirstLineLeftMargin = 0
  TableStyles(0).RightMargin = 150
  For ColumnIndex% = 0 To Ubound(View.Columns)
   Set Column = View.Columns(ColumnIndex%)
   If (Not(Column.IsHidden Or Column.IsCategory Or Column.IsHideDetail)) Then
    NoColumns% = NoColumns% + 1
    Redim Preserve TableStyles(NoColumns%)
    Set TableStyles(NoColumns%) = Session.CreateRichTextParagraphStyle()
    TableStyles(NoColumns%).LeftMargin = 0
    TableStyles(NoColumns%).FirstLineLeftMargin = 0
    TableStyles(NoColumns%).RightMargin = Column.Width * 150
   End If
  Next ColumnIndex%
  
  Select Case Typename(Category)
  Case "STRING","STRING ()"
   Set ViewNav = View.CreateViewNavFromCategory(Category)
   Set ViewEntries = View.GetAllEntriesByKey(Category)
  Case Else
   Set ViewNav = View.CreateViewNav 
   Set ViewEntries = View.AllEntries
  End Select
  Call iBody.AppendTable(ViewEntries.Count+1,NoColumns%+1,,RULER_ONE_INCH,TableStyles)  ' Create empty table
  Set RTNav = iBody.CreateNavigator()
  
' Output view title to first row
  
  TableColumn% = 1
  For ColumnIndex% = 0 To Ubound(View.Columns)
   Set Column = View.Columns(ColumnIndex%)
   If (Not(Column.IsHidden Or Column.IsCategory Or Column.IsHideDetail)) Then
    TableColumn% = TableColumn% + 1
    Call RTNav.FindNthElement(RTELEM_TYPE_TABLECELL,TableColumn%)
    Call iBody.BeginInsert(RTNav)
    Call iBody.AppendText(Column.Title)
    Call iBody.EndInsert()
   End If
  Next ColumnIndex%
  
' Output Data
  
  RowIndex% = 1
  Set DocEntry = ViewEntries.GetFirstEntry()
  While Not DocEntry Is Nothing
   Set Doc = DocENtry.Document
   Call RTNav.FindNthElement(RTELEM_TYPE_TABLECELL,RowIndex%*(NoColumns+1)+1)
   Call iBody.BeginInsert(RTNav)
   Call iBody.AppendDocLink(Doc,"")
   Call iBody.EndInsert()
   
   TableColumn% = 0
   For ColumnIndex% = 0 To Ubound(DocEntry.ColumnValues)
    Set Column = View.Columns(ColumnIndex%)
    If (Not(Column.IsHidden Or Column.IsCategory Or Column.IsHideDetail)) Then
     TableColumn% = TableColumn% + 1
     Call RTNav.FindNthElement(RTELEM_TYPE_TABLECELL,RowIndex%*(NoColumns%+1)+TableColumn%+1)
     Call iBody.BeginInsert(RTNav)
     If Isarray(DocEntry.ColumnValues(ColumnIndex%)) Then 
      Call iBody.AppendText(Join(DocEntry.ColumnValues(ColumnIndex%),","))
     Else
      Call iBody.AppendText(DocEntry.ColumnValues(ColumnIndex%))
     End If
     Call iBody.EndInsert()
    End If
   Next ColumnIndex%
   RowIndex% = RowIndex% + 1
   Set DocEntry = ViewEntries.GetNextEntry(DocEntry)
  Wend
  Exit Sub
  
Catch:
  Stop
  ReportError Nothing
  Exit Sub
 End Sub

Application Development has been essential to the survival and growth of the Notes client.  Prior to Notes 8 its was generally felt (and argued loudly at lotusnotessucks) that the Notes client was a vastly inferior offering to MS Outlook.  Despite this Notes held on and appears to be now gaining market share on Outlook.  This was due in no small part  to the inability of Microsoft to provide an alternative to Notes as a RAD tool for applications.  Microsoft also had Visual Basic and the .Net programming languages but still they couldn't win.

With the release of Notes 8.5 and the introduction of XPages, a new discussion has started within the yellowverse about programming languages.   XPages introduces a new offering in Server-Sided Javascript (SSJS) a new language with a syntax similar to JavaScript but also containing references to the @Formula language and the Product classes commonly used within LotusScript (e.g. NotesDatabase and NotesDocument).  As to be expected people are somewhat divided.  Not surprising given the programming world as a whole has never adopted any one single programming language.  The science of programming languages are continuing to evolve.  Object Oriented programming languages such as Java and the .Net family have been very popular of late and probably are still the #1 and #2 languages.  O'Reilly published an article based upon technical book sales which seems to show C# rising and Java falling   PHP and Python are popular in Web development but these no longer seem to be gaining ground.  C/C++, upon which Notes was originally built, is also losing ground.  Ruby is one of the more modern programming languages that are starting to gain ground.  It also appears that JavaScript is gaining in popularity.  Both Ruby and JavaScript support dynamic data types, a feature being seen as superior to strongly typed languages such as Java and C#.  The growth in popularity of JavaScript may be a good sign for the future adoption and success of SSJS.

And so what about LotusScript?  Well LotusScript I liken to Visual Basic and VB.Net.  Not just because they are BASIC-based programming languages but also because they tend to attract people who could be considered "less sophisticated"programmers.  This is an important group to Notes development because they are responsible for putting so many Notes applications on our Domino servers so quickly making it almost impossible for IT department to replace.   Are these people likely to move to Java? - I doubt it, to SSJS? (well maybe) or stick to LotusScript like they did when we were first offered Workplace? (also possible).  Part of that decision is tied to the design elements that also go into creating a Notes Application.  As things stand at the moment with 8.5.0 there is no doubt in my mind that the novice and intermediate Notes developer will produce a Notes application much faster using Forms, Views, Framesets, Outlines, Pages, and Agents.  An advanced programmer will develop a superior Domino Web application using XPages.  Will they be as productive? (apart from Tim Tripcony -  I am not so sure)  And 8.5.1 does bring XPages to the Notes client....  I posted an idea on ideajam suggesting IBM follow the strategy I believe they may already be following, which is focus all future effort on developing SSJS and retire LotusScript.  Hardly scientific but it didn't exactly receive overwhelming support.  Based upon this and many discussions and discussion threads I have to believe the Notes world is divided. 

I have long lamented the lack of support for LotusScript over the years.  But most of all I would love to see a single programming language I can use everywhere within Notes.  One that allows me to do OOP and one that allows me to be productive.  Has IBM made things better now we have SSJS?  We have @language that was the first language that can only be used in some places but is still the only choice for things like view selections formulae,  field validation on forms etc.  LotusScript is probably the most universaly adopted but not supported on client sided Web applications or within XPages.  Java is still limited where it can be used and has never gained wide-spread adoption.  JavaScript is used with client sided Web applications (including XPages) but is only  of limited value for traditional Note client applications.  And now SSJS which is presently only available for server sided XPages scripts.  That's a pretty clear simple and concise programming model right.  One that should be easy to learn, especially if you are a novice or intermediate Notes developer?

So I would put forward a suggestion....  If we are not careful we may end up making this great product simply too difficult and confusing for people to continue to bother?  The number of people able to master them all and hence go on to do really great things may not be enough to cover for a loss of interest in our yellow underbelly. If we are in fact all part  of an elaborate food-chain we might just see the Notes version of an algae bloom which will not only effect the Notes application development environment but the whole Notes eco system that includes Notes Mail, Sametime, Quickr and Connections.  Yes, its true, people can still program in LotusScript and build applications the old way.  But it is the "old" way and getting older by the day.  If it is not modernized without making it overly complex people will find their way to  newer, easier, technologies.  Technologies like Google Gears and Sharepoint already threaten and there are sure to be other new products coming soon.

So what is needed?...  Well I see two distinct strategies possible.  The first (and my preferred) is modeled on what Microsoft did with .Net.  Develop an intermediate language that drives Notes and make all the above languages compile to this base.  This allows people to chose the language of their preference/experience and also opens the door should a language such as Ruby gain popularity.  The other would be to pick a language that best meets the needs of the Notes "core" and then make it available to ALL design elements (not just Xages).  Both options allow a developer (or development team) to focus on a single programming language requiring less learning, greater productivity, and lower cost development.  But clear direction is needed from IBM.  Without it we will all head off in different directions.  Many people will stick with what they know for as long as they can.  We need something major to shake us all and steer us in a common direction.  That might be a design element like XPages should it ever become powerful enough to do everything the other design elements do (or at least 98%), allows us to do it faster,  is "reasonably" easy to learn, and delivers a superior user experience on a Notes client, Web client, and mobile device.   If I have that I wouldn't care what programming language I am using.  Hey, that's the reason why I am a Notes developer and bleed yellow in the first place!

OK, so there is more to 8.5.0 than XPages.  The following are a few of my thoughts as they relate to my experiences with the new Domino Designer for Eclipse.

The Good: A Modern IDE - The old domino Designer IDE was getting very outdated.  I had the opportunity to do development for a time with C# and .Net and hence can fully appreciate the power that a full-featured IDE like Visual Studio could bring.  And while I loved getting back to RAD with Notes I do still miss the power of Visual Studio.  I still don't see Eclipse as being anywhere near as powerful as Visual Studio but it sure narrows the gap.  The old IDE did a great job when development consisted of Forms, Views, and Agents.  With the addition of many additional design elements over the years and now XPages, Notes is now way more sophisticated and complex and clearly needs a tool like this.  At the moment it is a little clunky with the need to accommodate all the existing "legacy"? design elements and their individual idiosyncrasies but I am hoping these will eventually be worked out.  If you are like me and have not used Eclipse much in the past then there is a whole learning curve just with this new IDE to overcome in addition to learning XPages and SSJS.  If you are a full time Notes developer then I am sure after you have used this new IDE for 3-6 months you will never want to go back to the old IDE.

The Bad: A Complex IDE - As a full-time Notes developer, and one who has used a tool like Visual Studio I am not as intimidated by DDE as I am of XPages and SSJS.  On the other hand I am somewhat troubled that there will be a lot of non-programmers and part-time developers who will be completely intimidated by this new IDE.  To me Notes has been the success it has been largely because of this class of developer.  In my opinion Notes would not have survived being a mail client alone.  Many companies I have worked with would have replaced Notes with Outlook a long time ago if they could figure out an easy way to replace all the Notes applications that proliferated so quickly because of these "programmers".  How do these people view 8.5 and the new IDE?  Are they ever likely to adopt XPages and/or SSJS?  I recently blogged in a light-hearted way my own vision of how this might be solved.  I think the challenge is certainly there for IBM in moving the Notes Development platform upmarket to compete with Java and .Net to find a way to ensure a significant component of the yellowverse is not lost.

The UGLY: Where's MY LS Editor? - We may as well cover this one final time for completeness.  I am sure I am not alone in thinking that the single biggest disappointment with 8.5.0 was that IBM did not deliver a new LotusScript editor as anticipated.   I am sure IBM had gotten the message that this was one thing being sought by the yellowverse more than almost anything else.  To have not delivered simply means to me that IBM were not prepared to allocate enough resources to ensure it was completed in time.  I can perhaps understand why.  8.5.0 was also the release in which IBM launched a new programming language in SSJS.  So it was potentially an internal conflict to deliver a new programming language in the same relese as a new tool is made available that makes life easier to continue to develop applications in the established programming language - LotusScript.  The good new is that IBM have publically announced that it will be there in 8,5,1.  Because it is public knowledge I believe I am allowed to say that I have seen it and used it.  I just wish I had it  in 8.5.0. That would at least been some compensation for DDE 8.5.0 which feel a lot like the 8.0.0 Notes client - slow and fragile.  Again those aspects will be addressed in 8.5.1.

I typically blog about two things.  Books I am reading and my latest gadget :)  No, its my pet  .Domino Framework project on OpenNTF and my interest in the future direction of Notes.  In a way the two are interwined....

Jan Schulz  has posted a very good article questioning the future of LotusScript and the Notes client.  It is was one of a growing number of varied perspectives I have been reading with interest.  I have been asking myself similar questions over the past year since the 8.5 beta was first released.  I have also had the chance to look closely at the 8.5.1 beta, a release I have long said would be a pivotal release in Notes history.  And while I cannot disclose anything specific about 8.5., 1 I still feel this is the case.

I have been doing my bit to create debate within the yellowverse about the direction Notes development might be going .  Not because I believe I have the answers but because I believe it is a very important issue for us ALL to discuss.

1. The organizations for whom we all work must eventually decide about migrating Domino servers and Notes clients to 8.5.0 (and 8.5.1 when it  is released).  The Domino server side is much easier to execute and IBM have created a compelling business case for doing this.  The client side seems to often be driven by support issues and the functionality of the mail client.  Sadly few companies I have worked for are driven to deploy newer Notes clients to allow Notes developers to build better applications (but they should!).  Regardless of where you may sit on the arguments about the use of LS, Java, SSJS, XPages etc. having your companies upgrade their Notes clients to 8.5.1 is only going to increase your options as a developer.  You need to convince yourself that this release is important enought to fight for.
   
2. Whether you are a contractor or employee, your value as a Notes developer depends heavily on the skill set you have and the skills that are now needed.  Almost certainly there will now be some change in the skill sets that are being sought for Notes development.  So each of us needs to make decisions about what skills we want to develop to allow us to continue to be important to our current employer as well as make us attractive o prospective new employers.  This doesn't mean always moving the latest and greatest.  If you had jumped on the Java bandwagon when Java was first added to Notes you would have a skill that is of value but is still largely a niche market for Notes (I have never had a Java Notes developer work on any of my teams).  If you jumped onto the IBM Workplace bandwagon you would have made IBM happy but you would have acquired skills that were largely useless (except perhaps in now helping you with XPages).
   
3. It is no fun working with old code and companies seem to be forever replacing legacy applications.  If Notes code does change significantly as a result of XPages it would be better to stop producing legacy code sooner than later.
4. Notes has defied the odds to remain a vibrant product in part because it acquired a niche market.  It filled a void between low end Excel/Filemaker products and the high end Java/Oracle & .Net/SQL Server platforms.  It is classic marketing scenario, if we chose to leave our present market to compete in another more lucrative market (e.g. Web development) we better make sure we gain more customers than we lose.
   

Every change brings opportunity.  And those that profit the most from change are those that see it coming and position themselves to take advantage of the change.

We are seeing a lot of change in what is now being offered for Notes development but I am not sure the future of Notes is yet written.  That is because we have separate camps each being motivated by different things

1. IBM: I have long argued that Quickr and Lotus Connections could easily have been added as extensions to Lotus Notes giving both products the power of the rich client experience while still allowing a more universal Web client access.  Of course such an approach may not allow IBM to generate additional revenue streams that new products allow.  IBM also invested a lot of money into developing IBM Workplace.  They can only begin to recoup those costs if they find alternative products into which they can inject this technology.  IBM also has a product portfolio in which the common programing language is largely Java/Eclipse, with the exception of Notes and Symphony.  I am sure IBM want to see Notes form part of an integrated product offering and would love to see all us Notes developers programming in Java of SSJS.  I am sure Xpages is largely being added by IBM as a way of meeting some of these goals.
   
2. Notes Gurus: The Notes community has a relatively small number of people who are constantly finding ways to redefine just what Notes is capable of doing.  The best example of this is Lotus911's Bones project.  Most of the Notes gurus tend to be located in software development companies or large companies which invest heavily in technology.  This group are prominent in our community through blogs, presentations at LotusSphere etc, OpenNTF, and the Design Partner program.  Simply put their voice is probably a lot louder than the general Notes community combined.  It is in their interest to see technologies such as XPages come to the fore.  They are better placed than most to deal with the added complexities of technologies being added to Notes like  Xpages, Java, SSJS, Eclipose, Expiditer etc. and motivated by the superior quality of what they can then produce.
3. The Yellow Blob: Most of us are in a position where we must follow rather than lead.  We work with the version of Notes our employer provides.  We build Notes client solutions when asked for, and Web client solutions when called for.  We do have some influence.... We often do have a significant input into how our assigned projects are architectured and designed.   With XPages and Composite Applications we now have additional choices.  XPages adds a lot more capabilities to Notes but there are a lot of Notes things it still can't do.  It was not designed for Notes but adapted to work with Notes.  It also requires a whole new learning, something not all of us are in a position to do.  It will be up to you to decide the extent to which XPages and CA are adopted in your application design.  Customers don't ask for XPages and more than they ask for Java or LS.  They ask for functionality, ease of use, and performance (oh and for a low cost).  You must decide the most cost effective way to deliver those requirements with the toolset now at your disposal.  You do have a say despite what IBM wants -- you didn't follow IBM's lead with Java for Notes, Workplace or DB2 and IBM did listen.
   

My series of blogs on XPages are entitle "The Good, The Bad, and the Ugly": for a reason.  There is both a good side and a bad side to XPages.  And 8.5.1 probably provides more questions than answers.  There is some really powerful stuff there in 8.5.1 that we should all be pushing to get access to when it is released later this year.  What I can say about 8.5.1 is I do not see either the Notes client or traditional Notes client development going away any time soon.  Lets be clear, 8.5.0 was for Web developers, 8.5.1 is for Notes client developers.  It is public knowledge that 8.5.1 brings XPages to the Notes client.  But what exactly does it bring to the Notes client?  To what extent does IBM plan to bring the many great features already available to Notes application development into XPages.  The NSF container, replication, security, design templates, Rich Text editor, view control, outlines (including drag/drop), shared actions, shared fields, shared columns, personal folders, profile documents, name fields, Sametime awareness, and yes LOTUSSCRIPT.  Having seen 8.5.I have thought a lot these past two weeks about what it means for me.  I do about 95% of my development for the Notes client.  The XPages project I am working on at the moment is to enhance a dual client application in which the existing Web component was a little hokey.  XPages can fix that.  I am not walking away from the Notes client.  I believe strongly in the power of a rich client over a Web browser.  I believe given the chance to deploy and use 8.5.1 not only will I be continuing to do mainly Notes client development but  with the power it gives me I will be pushing to have Notes client applications displace Web-based applications being developed in non-Notes platforms.  Notes 8.5.1 is simply that good.  But it is not (yet) perfect.  In my next blog I would outline my view on what my ideal Notes development platform would looks like.

I don't normally plug my own ideas on ideajam, but this is one I would like to encourage notes developers in the yellowverse to cast a vote.  As many of you know from reading my blog I am in the process of learning how to develop xpages.  It is still early stages for 8.5, xpages ,and server sided Javascript but I am interested in getting and early indicator based upon your own experiences and insight as to whether or not xpages is likely to change Notes developer programming habits away from LotusScript towards Javascript.  Away from forms, views, pages and outlines to xPages.  IBM may or may not care but I am certainly interested.  It will help me decide what I do next with my OpenNTF project  .Domino Framework.  Do I continue to focus on LotusScript, do I turn my attention exclusively to xPages and Javascript, or do I focus on both?