![]() |
Home Email me SEARCH |
Monthly Archive
Blogroll
Abbas Lokhandwala
Adeleida
Alan Bell
Alan Lepofsky
Andy Donaldson
Arne Nielsen
Ben Langhinrichs
Ben Poole
Bill Buchan
BlogSphere
Brian Benz
Bruce Elgort
Captain Oblivious
Carl Tyler
Chris Byrne
Chris Coates
Chris Linfoot
Chris Miller
Chris Toohey
Chris Whisonant
Christian Brandlehner
CodeStore
Craig Schumann
Curt Stone
Damien Katz
Declan Lynch
Devin Olson
DomBlog.de
domlike.net
Duffbert
Ed Brill
Fabian Nirman
Ferdy Christant
Gayle Elgort
Grant Bingham
Gregg Eldred
Hassan Voyeau
Heini Schwammerl
Ian Irving
Jack Dausman
Jens-Christian Fischer
Jerry Carter
Johan Känngård
John Mill
John Roling
John Vaughan
Just Enough Governance
Justin Knol
Kathy Sierra
Keith Strickland
Ken Yee
Kevin Pettitt
Kurt Higley
Lance Spellman
Laurette Rynne
Mac Guidera
Matt and Jess
Matt White
Mikkel Heisterberg
Mrs Elsmore
Nathan Freeman
News4Notes
nsftools
OpenNTF Blog
Paul Mooney
PhotoTechno Reflections
Ray Bilyk
Richard Schwartz
Richard Spense
Rob Novak
Rob Wunderlich
Rocky Oliver
Roy Holder
Scott Good
Sean Burgess
Simon Peek
Squirrelly Notes
Stan Rogers
Stephan H. Wissel
Steve Castledine
Susan Bulloch
Taking Notes
Tim Rynne
Tim Tripcony
Tom's Rant
Turtle
Vince Schuurman
Volker Weber
Warren Elsmore
Adeleida
Alan Bell
Alan Lepofsky
Andy Donaldson
Arne Nielsen
Ben Langhinrichs
Ben Poole
Bill Buchan
BlogSphere
Brian Benz
Bruce Elgort
Captain Oblivious
Carl Tyler
Chris Byrne
Chris Coates
Chris Linfoot
Chris Miller
Chris Toohey
Chris Whisonant
Christian Brandlehner
CodeStore
Craig Schumann
Curt Stone
Damien Katz
Declan Lynch
Devin Olson
DomBlog.de
domlike.net
Duffbert
Ed Brill
Fabian Nirman
Ferdy Christant
Gayle Elgort
Grant Bingham
Gregg Eldred
Hassan Voyeau
Heini Schwammerl
Ian Irving
Jack Dausman
Jens-Christian Fischer
Jerry Carter
Johan Känngård
John Mill
John Roling
John Vaughan
Just Enough Governance
Justin Knol
Kathy Sierra
Keith Strickland
Ken Yee
Kevin Pettitt
Kurt Higley
Lance Spellman
Laurette Rynne
Mac Guidera
Matt and Jess
Matt White
Mikkel Heisterberg
Mrs Elsmore
Nathan Freeman
News4Notes
nsftools
OpenNTF Blog
Paul Mooney
PhotoTechno Reflections
Ray Bilyk
Richard Schwartz
Richard Spense
Rob Novak
Rob Wunderlich
Rocky Oliver
Roy Holder
Scott Good
Sean Burgess
Simon Peek
Squirrelly Notes
Stan Rogers
Stephan H. Wissel
Steve Castledine
Susan Bulloch
Taking Notes
Tim Rynne
Tim Tripcony
Tom's Rant
Turtle
Vince Schuurman
Volker Weber
Warren Elsmore
Notes and Domino 7 is very cool. There are many features that I think will be regarded as essential once folks have been using this version for even a short while (Autosave comes to mind immediately).
But not all new features are greeted enthusiastically. One feature of Designer that is fueling debate is the ability to rename design elements from the design view, without needing to open the element. Bruce has posted about this, as has Chris.
First off, Chris mentions that he can't think of a reason to use the same alias name on 2 design elements. Personally, I find this ability very useful if coding an application that will be accessed from the Notes client and the web client. This allows me to store the documents with a single form name, avoiding the need for form formulae in the views, and I can simply allow the design properties to control which form is used to render the data. That's a bit of an aside, but the point is that there are valid reasons to retain the design element name and alias across multiple elements.
Bruce's and Chris's points about the danger of in-view editing of design elements are well-taken. I happen to think this is a very cool feature, and I wish I could use it now in ND6. However, it would be much more intuitive if the properties were available via a right-button click of the mouse (or an Alt-Enter key combo after highlighting the design element). There's already a Design Document properties box that displays with a right-click. If one could set things like the alias from here (just like setting a database title via the DB properties box), that would preclude accidental renamings, and would most likely flatten a tiny bit of learning curve. I am not at all a fan of needing to edit the Notes.ini file to turn the in-view edit ability on and off, but I would be fine with enabling or disabling this via a Preferences dialog box.
The key to the whole thing is usability. The available parameters in the Notes.ini file are useful, but hardly intuitive. In-view editing is a wonderful feature in the client, so it makes sense to extend it to the Designer. And a means of managing this capability - via mechanisms with which folks are already familiar - would be a welcome enhancement.
Comments :
1. Posted by Christopher Byrne - website09/09/2007 08:42 PM
Honestly, I was not even thinking of design elements for the web vs the Notes Client. That is a very valid reason for them being the same. I was just thinking in more general terms. U shold update my posting to reflect this thought you put forth.
2. Posted by Jorge Coelho09/09/2007 08:42 PM
This is not unprecedented for new features in Lotus products. For example, compare the process of turning on/off debugger in 6.x vs. 7.x. The first attempt fell short, but they made it up for it the next time around. Hey ... at least they listen the 2nd time











