Bob Balaban's Blog


    Bob Balaban


    What if...."Java Views"

    Bob Balaban  September 29 2007 10:05:52 AM
    Greetings, Geeks!

    Please raise your hand if you are using Notes 8.0 on a regular basis.

    Ok, for those of you with your hands in the air (don't worry, nobody will notice), lower your hand if you do NOT know what a Notes 8 "Java View" is. I sure wish I could count the raised hands.....but I'm guessing something less than half of N8 users know about these. But, I could be wrong.

    Anyhow, let me try to 'splain it. In Notes 7 and before, there is special view-rendering code that knows how to draw a picture of any view on the screen. This code is very smart, written in C and C++, buried in some DLL or other in the install kit. It reads the contents of a View design note, interprets all of the settings, finds the appropriate data in the View's index, computes any formulas it finds, and draws the picture. Furthermore, this code knows how to handle user interaction -- keystrokes, mouse clicks, whatever, to do scrolling, lookahead, sort-on-the-fly, launch individual documents in an editor window, and all that stuff.

    This same code exists in Notes 8, but the actual picture-drawing and UI event-handling code is now different, because Notes is running inside an Expeditor/Eclipse owned window. Instead of calling down through an internal isolation layer to the Windows API, for example, it now calls (eventually) an SWT graphics package (coded in Java) inside Eclipse to do the rendering. But that doesn't matter, for most views, the picture looks pretty much the same as before.

    For some views, however -- Inbox, Calendar, in fact all the folders and views in your mail NSF, plus Contacts and a couple of other things I'll just refer to as the "PIM views" for shorthand -- you get special rendering. Instead of being drawn by the old Notes C/C++ code, these "Java Views" are rendered using Java code directly, with a rather different look and feel -- yes, some of the shortcut keystrokes work differently in Java Views, a fact which Mary Beth Raven is no doubt hoping I will finally leave her alone :-)

    This new view/folder UI was demoed extensively in the 2 years leading up to the release of Notes 8, and I think some people were rather surprised to discover that not all views/folders adopted it. There are several reasons for this:

          1) In order to make use of the new UI for views and folders, your app has to be structured as a Composite Application. The new rendering logic kicks in when Notes notices the presence of a special xml file in the database. Of course there also has to be a CompApp-friendly navigator pane, with the appropriate wiring set up between the 2 "components".

          2) Obviously, very few NSFs pre-Notes 8 (probably none of yours, certainly none of mine) were set up this way.

          3) This is a feature that might have been exposed in a general way, so that designers could "update" their NSFs to use Java Views. It wasn't, though, primarily because the need for extensive testing, documentation and samples would have delayed the release of the product. That's not to say it won't ever happen, just that it didn't get into 8.0

    So, fellow geeks, I have a couple of questions for you:

          a) Do you think that the new PIM UI (using Java Views) is better than the old UI? If so, what features of the new UI do you like most? If not, why not?

          b) On a scale of 1 to 5, where 1 is "don't care" and 5 is "If I don't get it, I'll die", how important do you think it is to be able to make any view or folder render as a "Java View"?

          c) I'll assume that nobody would object if what you (the designer) had to do to make this happen is, say, click on an InfoBox checkbox. But I'm trying to get a sense of how much work people would be willing to do to get this feature: would you be willing to go into Designer and do something for every view/folder you wanted to render this way? Even if you had dozens, or hundreds of changes to make? Would you prefer one setting per NSF, where the setting applies to ALL views/folders in the db?

          d) Would you be willing to transform your view into a Composite App in order to get the Java View rendering?

    I'm looking forward to seeing your comments. Keep those cards and letters coming!

    1Ingo Erdmann  09/29/2007 6:07:04 PM  What if.... Java Views

    a) Threading is my highlight. I don't like the fact that accessibility features such as ALT-number combinations to execute actions are not available.

    b) It's a 5 on the want-it scale. If users get used to the PIM rendering, they won't accept the old ugly rendering anymore.

    c) Whatever it takes, developers need to be able to use it. So I would be willing to do additional stuff to get it, certainly a click per view would be acceptable.

    d) If it is necessary to convert apps into composite apps I would accept that, as long as there is a concept of how these views will be incorporated within other higher level composite apps (right now, composite app in composite app is not possible).

    It seems to me that a per database setting would be desirable to get a unified look and feel for an application.

    2Rob McDonagh  09/29/2007 6:55:46 PM  What if.... Java Views

    a) You'll get comments hating the new selection model in the PIM views, I'm sure. I happen to like it, though, and I just wish it extended to all of my apps. Add to that the ability to render differently at different widths (I'm thinking of the way the Inbox behaves when you shrink its width, becoming two rows for each document). Oh, and preview on the side. Yeah, I like the Java views.

    b) 4. But I'm a tough judge. There aren't a lot of things worth a 5 in my book. JavaScript as the language of choice in all Lotus products - Notes client (and Exeditor), Symphony, etc, one powerful, flexible but also accessible language we can use everywhere - that's a 5.

    c) I would make the case that being able to choose this per view is a feature, not a limitation. There will be times when people will not want to change certain views, for whatever reason. I'd like to enable the PIM views globally, but I know that's not the only use case out there.

    d) I wouldn't like having to convert all my apps into CAs. In most of my apps, that's wasted effort. They are fundamentally not CAs. They're simple single database apps. Also, creating a CA is far more effort than ticking a checkbox on a design element property. And I'm giving the benefit of the doubt here and expecting that the existing Composite App Editor will be radically overhauled at the same time. If using that tool in its current state was the requirement, none of my apps would ever get converted and I'd stick with the traditional views.

    3Mikkel Heisterberg  09/30/2007 4:39:19 AM  What if.... Java Views

    a) Not better - different. I like that it can be customized to suit the needs such as vertical preview. This is really key for me - it is the feature that can adopt non-Notes data to be displayable like Notes data (same paradigm). I very much dislike that Alt-<number> doesn't work. Also it means that the experience isn't consistant across applications which has been a real strength of Notes.

    b) I would say 4. As stated above it will make it much easier to make Notes the one-stop application for displaying all out enterprise data.

    c) Let me tick a box and set the name of the Java class that implements the correct interface. For me it's okay that it's a little tricky - the key is that is is possible. That is okay for starters - let's focus on getting it and then how to make it easier to use. As to applying a style to multiple views there are third-party applications for that which for me is okay to begin with.

    As to class deployment/provisioning it should be possible to store the actual Java classes in the NSF / or possible on the server as well. Maybe it could be tied into the update site functionality as a forced feature.

    d) Nope.

    4Bram Withaar  09/30/2007 7:11:59 AM  What if.... Java Views

    a: better, more possible with them. As a developer i don't care for non working shortcuts, altough i do miss the 'old' notes selection model

    b. 4. I saw a demo at LS2007 where a java view was used to graphically show notes-data. That's huge! And i also like the tiled-view, want to enable it for our own employee db.

    c. Adjusting dozens of views can be done with third party tools or some dxl tweaking (make sure the new property is supported in Dxl!) I don't mind having to do some more work then. Especially when it get's less work in future releases. Creating composite apps and plugins etc. is also a LOT of work and clicking right now, so it's not unusual.

    d. don't mind, as long as i'm not forced to create wires and properties to get it to work. Click on a view name on the left, see the view on the right. It might be usefull in an app to have a java view, but not to make it into a composite.

    5Nathan T. Freeman  09/30/2007 9:25:33 AM  What if.... Java Views

    a) Well, what did we really get? Better but inconsistent handling of text popups. Improved width resizing. Threading. New selection model. Pure aesthetics.

    Of these, I suspect that the aesthetics make the initial impact difference for most users, and the width rendering (enabling the right-side preview model) makes the productivity difference. The other advantages of Java views are pretty marginal. Even threading only matters when you've been in a pure 8 environment for enough time for your mail usage patterns to catch up to system behavior (ie: you stop replying with history.)


    The trick is: I really don't think that Java views are going to allow me to build a better Notes app. Heck, I frequently prefer Notes apps that don't even really HAVE views, so does it make that big a difference whether the views I don't have are Java or native C++? If we had Java views available for custom apps, could we embed them? I suspect not.

    But, now you've got the PIM apps using a model that's different that what I can deploy myself. That's inconsistent. Inconsistent == evil.

    c) I'd rather get the higher resolution control first, and then get the easy-to-use switch later.

    d) No, I wouldn't. Java views just aren't that great. And they're really slow. The only real advantage for my own applications would be multi-line rows in views.

    6  09/30/2007 6:21:53 PM  What if.... Java Views

    a) Better - only slighly: default action / split buttons for action buttons is useful, solid highlight for current row. Basically it is prettier rather than better. But I prefer the selection model as it applies in non Java views (combination of old and new).

    b) Probably 4, for consistency of the UI more than anything else.

    c)A couple of clicks per view would be fine. I think you need that granularity. Per database is too broad.

    d) Using the current methods, composite apps would be too complicated and I wouldn't bother.

    My concerns are mainly around deployment. What CSS would it use? Would you be limited to the installed CSS file which controls the PIM views? This is on file in the program folder, not in the application. Things like this would need to be resolved (if you could link it to a page or resource within the database that would be way cool).

    I see great potential too. Particularly if you had the option to specify a differnet Java resource to render the view. But I guess that functionality is more a part of the composite app than Notes itself.

    Some of those boundaries are still a little conceptually blury for me and it is exciting to see how it will all come together.

    7Chris Toohey  10/01/2007 9:59:17 AM  What if.... Java Views

    This - honestly - doesn't sound like something that I'd be all that interested in (sorry, being honest here) as I tend to do what you're suggesting (if I get you right that is...) with more malleable solutions...

    But you did hit on something that I would like to see improved: View modifications.

    We've all (the majority of us anyways) been there - you go into an older application onto to realize that the UI of the views need to change drastically, or you've got formula that needs changing etc.

    It's gotten to the point where I have Shared Actions that lookup functional code in a "settings" document while checking to see if said action needs to even display. As for the view content itself - I typically rely on "viewCol1"-type fields in the documents that I can conditionally change, etc. I still have problems however with these "solutions" as they can cause replication storms and they don't even address the UI!

    What I would like to see if a simple method for maintaining the look of Views - think CSS, with Colunmn width, font-attributes, etc. all defined in a shared CSS resource. We define IDs for given Columns and whammo - we're set.

    IMHO - we should be spending the development cycles shoring up what's already in the product instead of looking to implement features that really don't make an impact to your current users.

    I know developers (and I get what they're saying...) that will keep as many views out of a given application as they don't want to go back in and change things around once they get the application into production - View Maintenance today is a damned nightmare! I fear that adding more on top of the View engine without giving us developers a way to maintain said View elements with a cleaner, more "enterprise-level" solution is a tell-tale sign of going in the wrong direction.

    -- sorry, done ranting! ;-)

    8Brian Miller  10/01/2007 11:08:05 AM  What if.... Java Views

    The right thing to do is to completely expose the wiring for custom-creating our own display mechanics through writing a Java class. Outside of that, I wouldn't really bother with doing much to bring "java views" into everything else. If you could get the PIM views types to be "click-a-checkbox" easy, like calendar views (almost) are, that would be worth doing. Outside of that, I don't get the "big win", unless I can completely define how a view looks myself, down to the pixel.

    Something else that's been barely grazed upon - I've been dying for capturable/programmable keyboard shorcuts for a while now. I've been excoriated in the past because I couldn't have an action bound to something *besides* Alt-#. I figure I'll get this if I can wire up the visual Java elements myself, but I really want something like onKeyPress. I also might get that from client-side JS, and that's OK as well. As long as I get there.

    I don't think anyone's going to like the idea of creating a CompApp where it's not necessary/useful.

    9Stephan H. Wissel  10/01/2007 1:59:06 PM  What if.... Java Views

    Expose the Java Views for consistency. Write a developer works article how to batch-update existing apps using DXL or any other means...

    I would love to have the Alt-# back (and default actions in forms/pages too).

    And: expose the API / document the interfaces. There is a huge opportunity for new ways to show view data. There are so many ideas, that IBM alone won't be able to implement them all (can you spell: budget justification) and a BP might quite happy do them.

    :-) stw

    P.S.: a 5!!!

    10Charles Robinson  10/01/2007 2:39:49 PM  What if.... Java Views

    a) Not better, just different. I have no strong opinion either way as far as the look, feel, or usability. As for the "why not"... well, it's because of the poor performance and instability of the Notes 8 Standard client. I won't beat that dead horse here, if you want more information let me know.

    b) 1 ... I don't see that they offer much real value over what I can do with the C/C++ views. The only thing I really like is whatever that style is called that is used for the business card view in Contacts.

    c) For consistency's sake I would prefer to change it at the NSF level. Having to update every view individually would suck.

    d) Not really. That sounds like a lot to go through just to get pretty views with marginally more functionality.

    11Tony Palmer  10/02/2007 1:29:14 AM  What if.... Java Views

    a) haven't had enough time to look at 8 in enough detail to comment what's good and what's not for the views.

    but from a - I'll probably use this in the future....

    b) but should be consistent

    c) view per click is better

    d) nope - it should be simple

    12Arjan Uijl  10/02/2007 7:10:04 AM  What if.... Java Views

    a) better, more functionality is available to the designers so more enhancements can be made

    b) 5 If I don't get it, I'll die

    c) I feel different view handling/look & feel for all applications is killing. From user perspective there should be one and only one user interface and the way a view should act. Notes 8 users are now working in the new mail application with java views (e.g. selecting documents with ctrl) and in all the pre Notes 8 applications they work with the selection margin for selecting documents.

    d) there should be a simple way of upgrading those views.

    13Wayne Sobers  10/02/2007 7:39:56 AM  What if.... Java Views

    a) Just different. As others have noted, the new selection method is a mixed blessing.

    b) 5 .

    c) This could be done as a utility nsf that could perform the conversion

    d) No

    I also agree with Brian Millar - get "onkeypress" working natively for the client.

    14Hynek Kobelka  10/02/2007 2:55:22 PM  What if.... Java Views

    a) I like the JavaViews UI better. (But they seem to open much more slowly)

    b) 5 its important. Especially when customers tell me to make it look like the mail views. What should i answer. I can't ?

    c) I don't care. If you force me to do it on every view separately, then somebody else will build a tool to do it convenient.

    d) Yes.

    The JavaView gives me only a nicer UI and a different selection model. Nothing else.

    The features i would love to have are actually something like:

    - computed view titles

    - computed keyword-aliases from a profile settings (or somewhere else)

    - selection of documents from other databases (not only in DB2-views)

    - perfectly working embedded-views with "show only one category" (Ctrl-A, Collapse All, ...)

    Sorry I know that this has not been asked, but I simply can't miss this opportunity to ask for this again.

    15Stan Rogers  10/04/2007 11:38:02 PM  What if.... Java Views

    a) Better -- at least for a significant subset of application and data types. Strict tabular representation is good for what it's good for, but it's a really awkward way to present free-range content (or an excerpt thereof). We've been building web-enabled apps with views like that for quite a while, and I've had more than a few users opt to use the web version just for the UI "candy".

    b) Somewhere between 7 and 9 (and yes, I know the scale is 1 to 5). User acceptance is everything -- no matter how well-sponsored an app is.

    c) View-at-a-time would be better. Some data are still best represented the old way, and there's no need to throw an extra layer of slow into something that doesn't need it. Consistency across types would be nice, though -- the user shouldn't have to know that they're working in one type or the other, so the things they do should work the same way everywhere.

    d) That's the reason I've built web-centric apps in all-Notes shops in the past -- to create composite apps. I don't know whether or not it OUGHT to be a requirement, but I wouldn't be too terribly upset if it were. They come in right some handy anyway, Java views or not.

    16Michael Bourak  10/08/2007 7:13:09 AM  What if.... Java Views

    a) Java views because they allow more modern look n feel and greater flexibility in some parts (resising)

    b) 5. It's the first thing that I was asked by customers : can I make my views look like this... What I like to is the - hopefully forthcoming - ability to provide my own "renderer" to views (like the "business card one" in the adress book.

    c) a per view checkbox and a default value at the db level.

    d) well, I don't see why the "java" rendering should be - in the future - coupled with the app beeing a composite apps...

    But as said, Java views don't solve some annoying shortcomings we have in embeded views : single category and sorting, being able to select target views etc...

    17Dan Sickles  10/08/2007 12:13:05 PM  What if.... Java Views

    @8 get's it right. I would like to implement my own java view renderer that leverages the existing c++ view model code and without writing a separate plug-in.. Just give me an interface and tell me how to bind it to a view. I would then be free to build any UI for my view, not just some variation on rows/columns. As for performance...please just let me shoot myself in the foot.

    As for the R8 java views:

    a) yes because it will be easier for Lotus to enhance the functionality in R.? than with the old view rendering.

    b) 5

    c) @16

    d) I'd prefer that it not be required.

    18Erik Brooks  10/08/2007 2:21:06 PM  What if.... Java Views

    So I read this topic headline, and I'm thinking "Are they seriously discussing keeping the Java View Applet??!!?!" LOL!

    a) Slightly better - asthetics.

    b) I'm with Nathan @5 - personally don't care, but for users, inconsistency = bad.

    c) Fall back to my mantra - #1 is the stuff Notes can't do AT ALL, #2 is the stuff that isn't RAD. So satisfy #1 first and do the per-view checkbox first. Do #2 later, or - better yet - get DXL importing/exporting of views perfect and we'll just do it ourselves.

    d) I really don't care. All of our dev is for the web -- I'm just adding my $0.02.

    19Andrew Tjecklowsky  11/30/2007 6:37:49 AM  What if.... Java Views

    Bob can you confirm that this is NOT going into the 8.0.1 release?

    If it isn't.... is IBM considering "dropping" it so we - developers - can't ever make our own customization?

    If so... when will we - if ever - be able to create an Eclipse View instead?

    20Andrew Tjecklowsky  01/06/2008 2:20:13 PM  What if.... Java Views

    Anyone knows if this is going into 8.0.1? We've really been looking forward to be able to extend the views like this. Please post links to IBM pages with statements if possible. Thanks.