This was my latest start all week. And no, it's not because Myron was with me so get your minds out of the gutter. I had stopped by the UX labs the previous day and the only time they had for me to test drive Domino Designer 8.5 was 9:00 AM.
9:00 - UX Labs - Domino Designer 8.5
Margo Ezekiel
One of the coolest things was when I walked up and introduced myself and Margo remembered that I had commented on the design persona for
Raj. They
are paying attention! There were several sessions at Lotusphere about Domino Designer, and Maureen Leland has posted some pictures on her
blog. You may want to review those as you read along here, since I wasn't able to take any screenshots of my own.
At first glance Domino Designer in Eclipse is really familiar. The biggest change is the Bookmark bar is gone. For the.. um.. none?... of you who used Bookmarks in Designer, you'll have to get over it. As for the rest of the layout, you have your database navigator on the left and the currently selected design element displays on the right. One great enhancement is you no longer are limited to seeing only five of a certain design element at a time in the navigator. If you expand Forms, you get a list of ALL the forms.
One thing that threw me a little was the property page that is at the bottom of the screen. It is a series of tabs that shows the properties of the currently selected item. The first tab, which I think is labeled General, is always visible, and other tabs appear or disappear depending on what you have selected. What it doesn't do, though, is tell you what you have selected. Today when you select a Form, the Infobox says "Form", or if you select a database it says "Database". The new property pages don't do that, and as you'll see when this lack of information is coupled with some of Eclipse's features it creates a massive usability issue.
I really like that you can move around anything in the UI, so you could move the properties to the side or float them, and you can resize it. I didn't find an easy way to recall the properties if you float them then close them. Something new here is that you can copy out of the property window, which means you can finally copy a replica ID. Yay!
A totally new concept is Work Sets. You can group databases together so when you select a particular Work Set, it clears the navigator and shows the databases in that Work Set. This is particularly handy when doing multi-database work, or when working with databases from multiple clients. You can create as many Work Sets as you like to arrange your application development efforts however you want. Of course you don't have to use Work Sets, so you can continue just using the standard navigator you've always used.
In the 8.5 Beta I was using creating a Work Set was a little awkward. When you brought up the list of databases to select from it was a rather unattractive list that showed the filename and the database title, like this:
hr_database.nsf;HR Database
it_tickets.nsf;IT Trouble Tickets
With a few dozen databases in the list it was difficult to navigate. I suggested that they show the database title first, and they put it into a grid so it's easier to read. After all, who really remembers the filename of a database? You see the title most often, so that's what should be visible first. Having the filename is important, but not the most important thing.
An interesting thing about Work Sets is you could end up with the same design element in multiple databases. I wasn't clear on whether it was simply name matching ("Customer" form could be in two different databases in the same Work Set but actually be completely different) or based on inheritance or design note ID's. Anyway, the reason I'm bringing this up is because the way it is currently implemented if you have a design element open in the editor it will show a selection focus around all the databases that contain it. Since I'm not clear on how this is determined I'm not sure what that's supposed to do for me. I think I would rather just have it highlight the one database I'm currently working in (like Designer does today) and have a separate Inheritance Hierarchy navigator to show me where the current design element will end up.
I'll cover more about XPages shortly, but I wanted to talk about the XPage editor for a minute. You can drag controls onto the page and bind them to a datasource, which you can create on the fly. Your data can come from Notes, an RDBMS, an XML file or even a web service. You can have multiple datasources represented on a single page. When you open up the dialog to select a Notes database as your datasource it's identical to the one to add a database to a Work Set. That is, it's hugely unappealing and difficult to navigate. It also doesn't start with the databases you currently have open in your Database Navigator or Work Set. I suggested that as a start, as well as separating it into a grid.
While editing an XPage you learn that a lot of the properties of the controls on the page are computable. For example, you can compute the values in a combobox based on the value entered into a field, or the selection in another combobox. Margo asked me to compute the value for any property I could, which brought up the question: How do I know what is computable? At first glance I couldn't figure it out. I scoured the screen, I looked at multiple control types, and I even tried searching the help. I finally started clicking on everything I could find on the screen. Margo eventually had pity on me and told me that any property with a blue diamond beside it is computable. Not the most intuitive mnemonic, but I could learn it. I was told this is a holdover from Workplace Forms and Lotus Component Designer, and they're working on the right mnemonics for Notes. She said they were considering an @ sign or perhaps a graphical "fn" designation, both of which were more immediately obvious in other tests they had done. If you see any preliminary screenshots just know that the blue diamonds mean you can enter formula or Javascript to compute the value.
While working with Designer 8.5 I got annoyed by two things. First, you have to double-click in the database navigator to open a design element. Margo said every single person she had worked with during usability sessions, both before Lotusphere and at the conference, had the same reaction: click the design element once and wait for something to happen. Either they would ask if it's broken or they would try double-clicking.
Thinking that it was insane for every single person she had ever seen to have the same usability issue, I questioned why this was left this way. She said they had intentionally made the decision that it would be better to retrain Notes developers for some features of Eclipse rather than make Eclipse more like Domino Designer. I pointed out that this was Domino Designer, not Eclipse. She started to argue with me, but after that sank in for a few minutes she reacted like she had never considered that point of view before. Yes, you can use Domino Designer 8.5 for both Notes, Java and Expeditor development. I truly don't care. It's Domino Designer, and making every Notes developer learn the Eclipse way just because Domino Designer is fronted by Eclipse is ridiculous.
Te second thing that got confusing was figuring out what had the focus. Consider the following picture (from Maureen's blog):
The Save button obviously has the focus so what is the property window showing? If you look at the navigator on the left you can see the qt1a XPage is selected, so it's the properties of the XPage design element. But the Save button is selected... how is that possible?
Simply put, you can have multiple things selected at once. Each Eclipse view maintains its own selection focus. Your only indication of what is selected is the property window, but the property window doesn't clearly tell you what you currently have selected. You have to derive it based on what properties are visible. At one point I had as many as four different things on the screen with focus highlights but I couldn't tell what had the focus. This
really needs to be addressed.
I love the functionality that is coming with Domino Designer in Eclipse, but I sincerely hope that IBM doesn't try to change 15+ years of naming conventions and 10+ years of usability overnight. I'll be the first in line to set fire to the old Domino Designer (sorry Andre, Maureen, et al.), but there are parts that work and changing them for no good reason would be a tremendous mistake. Designer 8.5 in Eclipse should just be another release of Designer. It shouldn't try to turn Notes developers into Eclipse developers.
I'll go on the record saying I'm not a fan of Eclipse. I have downloaded it multiple times and tried to use it for HTML, CSS and Java. I've even tried using it for Ruby, Perl and PHP. In every case I have found it confusing and downright bad from a usability point of view. My biggest issue is it introduces a wholly new naming system that has absolutely nothing to do with anything else you've ever seen, and I don't understand why that was necessary.
It's not a design window, it's an
editor. It's not a property window or database navigator, it's a
view. The combination of editors and views creates a
perspective, which you can supposedly somehow save together. And somehow perspectives relate to
workbenches, but that one is just too obtuse for me to fully grasp. The Eclipse terminology was peppered throughout my UX session, and it quickly got annoying having to translate everything. I would be asked to "use the Navigator view" and I'd go to the database navigator, expand Views, and look for "Navigator".
[Note: I don't intend to open a discussion about Eclipse terminology here. I'm simply pointing out that it's totally foreign for the majority of Notes developers, and IBM's slavish adherence to it creates a cognitive gap for their customers. From what I saw IBM is trying to ram this down Notes developers' throats in Designer 8.5 and I don't like it one bit.]
11:15 - Advanced LotusScript: Design Programming using XML and DXL
Andre Guirard
DXL can be used to update many design elements in Notes. This involves exporting a design element, making changes, and reimporting it. You can also export design elements, apply an XML style sheet (XSLT) using NotesXMLTransformer, and then get information about your design elements.
To get DXL out of a database you use NotesDXLExporter. To get it back in you use NotesDXLImporter. There is a menu in Domino Designer to kick off the Exporter, but not one for the Importer. You'll have to code that yourself. Anyone with Reader access or higher can export a NotesDocument, but you will need Designer or Manager to import any DXL.
DXL is just a text file, so you can parse that manually if you like. Notes has two built-in objects to help you work with DXL, NotesDOMParser and NotesSAX Parser. The difference between the two is NotesDOMParser simply takes an XML document (it doesn't have to be DXL) and presents it as a document map. You can either iterate through this manually and parse the XML, or you can hook the NotesDOMParser into a NotesSAXParser. The SAXParser will trigger events based on the tags you specify.
Andre Guirard has published the
Design Element Finder application which uses DXL to locate a design element.
mp)
