GoogleIt Mail IT Print IT PermaLinkTough Love? Or Just A Tough Crowd?
11:54:31 PM
Written By : Richard SchwartzCategory : IBM Lotus Notes And Domino
Location : Nashua, NH

I'm tempted to follow Micheal's and Chris' example by doing "Conversations" posts on a regular basis. I've actually been tracking conversations that I participate via links in the "Responses Elsewhere" block which you can see on the right if you scroll down a bit. But links are just links. Saying a few words adds value. (At least I would hope that it does, on occasion.) But before I make it a regular feature of this blog, I'll have to come up with a catch-phrase. First thing that comes to mind is "The Schwartz Is With Them...", but that might be belaboring this "Schwartz" thing just a bit too much.

Anyhow, there are two conversations going on that I want to mention briefly. One has crossed two threads over at Jake Howlett's CodeStore. First of all, let me say that Jake makes a valid point. He's correct on the facts. There's no disputing that, and we can talk until we're blue in the face about all the good things in ND7 and all the great things that will be in Hannover, and Jake will still be absolutely right in what he said. But he's coming at it from a narrow perspective, and while he says that he's asking "what's in ND7 for me?" from his web developer perspective he's actually asking something even more narrow than that. He's really asking "what's in ND7's functionality for my capability and productivity as a web developer?" The answer to that latter question is, truthfully, very little more than what was there in ND 6.5, but that misses the point. For the larger question of what's in it for Jake as web developer the answer is: a strengthened Domino platform, better able to meet the needs of the thousands of customers with with more than a hundred million users, who provide the demand for Jake's Domino web developer services. If IBM doesn't do that, giving web developers a whole raft of nifty new features won't mean a hill of beans. IBM has chosen to focus ND7 almost exclusively on this broad and important goal, and we can wish all that we want that they could to that and throw a few cool features at web developers simultaneously, but IBM decided not to go that route and who are we to know better than IBM how to most effectively manage their resources and their priorities?

Even more than the previous conversation, the next one makes me think that being in IBM's shoes must really be tough in the first few weeks or months after a major release. After all the careful thought, all the planning, and all the work that goes into a release, there's always going to be someone out there who points out something that IBM knew in the first place, and holding it against IBM anyhow! The other conversation started with Bruce pointing out that Domino Designer 7 allows editing design element properties at the "view level". (Technically, it's similar to a view, but not a view., but be that as it may...) One of the commenters wrote: "Someone in Westford said, 'Hey, let's enable this,' and now we are stuck with it." Uhhh... no. I don't think so. I believe that this has been asked for. Asked for repeatedly, at Lotusphere, and elsewhere. And I have a pretty strong recollection of IBM developers coming back with "Are you sure you really want this??" I could be imagining this, but I don't think so. Chris has framed the issue in terms of risks and controls. No surprise there, of course, but frankly I think he misses the mark on it when he writes "The bottom line is that IBM should not have introduced a feature that potentially weakens an enterprise's application development controls environment without putting some safety valves in place." He's entirely correct that in-view editing of design elements increases the risk of accidental design element changes, but let's not kid ourselves here: Domino Designer is not plugged into any enterprise quality sortware configuration change management system, and it's fraught with ways for developers to screw themselves up. Since there has never been a way to open up a design element for read-only access, there has always been substantial risk of saving unintended changes. The addition of in-view editing provides only a small increase in the risk inherent in doing development (in Domino or any other programming environment for that matter) without a formal framework or regime for change management. IBM has left development of source management tools to 3rd parties and although there's only one out there that everyone knows about, there have been others -- and I know of several efforts people have undertaken to roll their own. If there were really a huge amount of pent up demand for solving this inherent problem with Domino development, there would be a stronger market and there would be several viable alternatives on the market at reasonable prices. I'd like wrap this up now on a positive note: Domino 6 introduced design element locking, and though I haven't tested it, I believe that it should prevent in-view editing. It seems to me, therefore, that if we're really concerned about inadvertant changes to design elements, then instead of talking about disabling this one new feature what we ought to be talking about is developing a lock and unlock regime, and tools to support it, which will allow us to protect individual design elements.

This page has been accessed 218 times. .
Comments :v

1. Christopher Byrne09/27/2005 09:43:37 AM

I don't think it so much that I missed the forest in the trees, but I was ignoring the bigger issue for now and focusing on this one area as a concrete example (dropping hints at change management controls). The bigger issue is being addressed in an article I have on Change Management in Domino coming out in the December issue of Lotus Advisor.

You are "spot on" in the problem of Domino development being outside of corporate change management processes, which is a whole post in and of itself. But I strongly feel that a vendor should not introduce a feature that adds to risk without simple ways to disable/control it.

2. Debbie09/27/2005 10:23:34 AM

I have a question about all this fuss, but I'm not sure what blog to put it in, so you get it here. I can definitely understand the shock factor of inadvertantly changing a design element name and the potential risks. But, how is that any different from what we do to our users with the in-view edit? Do they get a warning? Do they get an 'Are you sure?' Nope. Once they click in that spot, they can lose it all and they might not even notice it if it happens too fast and they click elsewhere immediately. As developers, we'll find out when something stops working

So, if you take a survey of your users when you implement the in-view edit to see how many want it and how many don't, who wins? And if those that want it win, do you provide the rest a way to turn it off?

I'm not taking sides on the issue, just asking a question.

3. Julian Robichaux09/27/2005 12:13:55 PM

@Debbie - if you're adding in-view editing to a Notes database, you can use InViewEdit events to intercept what's going on.

For the Query or the Validate events, you can tell the user that they're either about to go into edit mode (Query) or that they're about to save their changes (Validate). In both of those circumstances, you can prompt the user and set Continue=False to cancel the action.

4. Debbie09/27/2005 01:11:03 PM

@Julian, and that my friend, is why I ask these things! Thanks!

5. Richard Schwartz09/27/2005 01:30:31 PM

Wow, this discussion just rang a bell. Way back in 1998 when a discussion of "spreadsheet-like views" came up in the Lotus Partner Forum, and we were bouning around a number of different ideas, I wrote this:

Try this for Plan B: Forget about requiring the form formula. Don't use any form. Do the whole thing with two new script events defined in the View: QueryOpenDocInGrid and QuerySaveDocFromGrid. For bonus points give us Post versions of both events too. Give us a new object NotesUIGridRow which contains NotesUIGridColumns that correspond to the view columns. Let us write code in the QueryOpenDocInGrid event that loads the values into each NotesUIGridColumn.value within the NotesUIGridRow, and let us write code in the QuerySaveDocFromGrid event that saves the values from NoteUIGridColumn.value into a back-end NotesDocument. That way we have complete control over transitions from storage to display and back to storage. And give us view events for QueryCellChange and PostCellChange that would allow us to do whatever we want or need when a user tabs out of a changed cell or clicks a green check box, That way we can update calculated cells too. Although this plan would make this feature accessible only to script programmers -- and that's clearly less desirable than one that can figure out what to do all by itself from the view column definitions -- I could live with it

6. chenjinyan11/22/2016 02:55:59 AM
Homepage: http://

7. 20161125caihuali11/25/2016 12:24:11 AM

8. chenyingying12/01/2016 09:20:45 PM

Enter Comments^

Email addresses provided are not made available on this site.

You can use UUB Code in your posts.

[b]bold[/b]  [i]italic[/i]  [u]underline[/u]  [s]strikethrough[/s]

URL's will be automatically converted to Links

:-x :cry: :laugh: :-( :cool: :huh: :-) :angry: :-D ;-) :-p :grin: :rolleyes: :-\ :emb: :lips: :-o
bold italic underline Strikethrough

Remember me    

Monthly Archive
Responses Elsewhere

About The Schwartz


All opinions expressed here are my own, and do not represent positions of my employer.