After a long time I picked up one of my favorite tasks: building Online Help. Having said that I am quite sure a substantial number of you will frown as I know from the past it was not common that people around me did really like that.

So why do I like it? To me it's one of those missing links a user experiences when confronted with some nice peace of software he should start to use and the fact that there is no one around to instruct him in some way. Oh yes, I know NAV Online Help (OLH) is not always the best gap filler, but it's there and to be honest the UA team has really done a much better job on Online Help lately.

Did you manage to get Online Help in place?

But OK, I had not intended to write a post on what I like doing. No, while working on this Online Help project I was actually remembering all the fuss I had gone through years ago trying to master the full extend of creating OLH. In my case I was working on the help for the Dutch Telebanking module at the time our GDL team started to pick up the localization of NAV 4.0 (or what was then just renamed Microsoft Business Solutions - Navision). Getting to understand the various tools, the various steps to take and not in the least how to phrase so that my topics would not differ too much from the standard topics. Oh, and of course understand the functionality to it's full extend. I would almost forget that, where it typically was a big challenge as Telebanking already existed for some years, only little documentation existed and the initial developer was long gone. Most probably a situation not unfamiliar to most of us.

So I was wondering how did you all manage to get the Online Help for your add-on in place?

CfMD

You know a couple of years ago, way before MS did lay me off, I was considering to go out on my own offering my OLH expertise. So I conducted a small survey among Dutch NAV partners. It was clear cut that quite some of them had not done anything around OLH. For obvious reasons like the ones mentioned above next to little to none direct need for it. In the mean time, however, MS set up the Certified for Microsoft Dynamics (CfMD) program which a.o. made it compulsory to have OLH for the add-on you want to certify.

So how did for all these get OLH in place?

Can I invite you to enter your answers to my questions below?

Sunny Sunday morning. Everyone still dead asleep. Perfect time to pick up what I had started months ago: my HIRS@M series. Sorry for keeping you waiting.

#1 - Purpose

In this post I want to shed light on the purpose of reviewing specs. Reasons for which I value a review; reasons often overlooked IMHO.

And next?

So this is #1. What's next? #2 and #3! Promised. However no promise when.

Let me give a sneak preview:

• #2 - Practice: so how did I (we) perform a review
• #3 - "after Party": so once the spec has been reviewed and implemented, "what value does it have?"

As I implicitly pointed out in the prologue of this series good speccing is about driving quality upstream. Good speccing is about making sure you are designing what is needed. Not a Pontiac Aztek, when a Roll Royce is wanted. Or indeed a Pontiac Aztek, if that is what's asked for.

So what's good speccing?

There are many actions, many skills, many requisites that make up and define good speccing and one of them is spec reviewing.

BTW: if you are looking for the full Monty on specs I would like to recommend you Karl Wiegers' Software Requirements.

Team effort - Multiple Perspectives

As with many disciplines speccing is a team effort and actually I would say: should be. For this reason the multidisciplinary development teams I worked in at MS were involved in getting specs in place right from the start. Whereas the program manager(s) (PM) would primarily be gathering requirements and writing the spec, dev, test and, if available, UA (i.e. user assistance being the documentalist) first contribution would be reviewing this. This setup would facilitate a multi-disciplinary, and as such a multi-perspective view on the matter. And thus, as Steve McConell states it in CODE Complete:

Page 482:

"Better code quality arises from multiple sets of eyes ..."

To me it's as plain as that: multiple sets of eyes looking at the same. You often even do not need to be a an expert on the topic to be able to make a valuable contribution to a spec review. Well skilled spec writers do often enough experience that their initial perspective was too narrow! Missing a wide enough range of perspectives/disciplines in spec review potentially inflicts problems down stream. Or as Wiegers points it out with respect to involvement of the customer:

Page 33:

"… we know that lack of customer involvement greatly increases the risk of building the wrong product"

At the end of the day it's all about cost. Every hour spend on reviewing pays off:

Page 263:

"Several companies have avoided as much as 10 hours of labor for every hour they invested in inspecting requirements documents ..."

From multiple sources McConnell calculates the relative costs for fixing defects based on "when they're introduced and detected":

Or in words:

Page 28:

"In general, the principle is to find an error as close as possible to the time at which it was introduced. The longer the defect stays …, the more damage it cause further down the chain"

The numbers depend of course on the type of software development business you're in. When building a solution specifically for a very small group of customers defects introduced at an early stage will not have as dramatic (cost) consequences as in case of building a standard solution for hundreds or thousands of customers, like Dynamics NAV.

Team Effort - In the Know

IMHO it's not only the multitude of perspectives during reviewing that helps to drive quality upstream. It's also the simple fact of getting a team engaged. In general, being part of a process from the start creates bigger involvement, as people will be in the know and feel and know they can make a difference, and thereby set to contribute to the quality of the product. You might say this is true even when the team members concerned do not (always) actively made contributions to the spec review. They where there, they got the opportunity.

It's clear that "everyone owns quality" as How We Test Software at Microsoft states (page 392), so you better make sure your team is in the best position to carry this weight.

References

1. Wiegers, Karl, 2003, Software Requirements, 2d ed. Redmond, WA: Microsoft Press
2. McConnell, Steve, 2004, CODE Complete, 2d ed. Redmond, WA: Microsoft Press
3. Page, Johnston, Rollison, 2009, How We Test Software at Microsoft, Redmond, WA: Microsoft Press

Fortunately for all Dynamics NAV pro's, some years ago, PACKT Publishing stepped into the hole in NAV documentation that had been there for years. With their last book, written by my fellow country man Mark Brummel, another and persistent gap was filled: the one left between Implementing and Programming Microsoft Dynamics NAV 2009. On this Mark has done a tremendous job "to cramp so much information in so little space ", as kriki states it.

With this review, however, I have not set out to give a complete review on all topics covered by the book, but simply want to highlight those that struck my eye.

Clearly Mark's adage "Look, Learn, Love" applies to his book too. It undoubtedly adds a new perspective to NAV documentation which, even for celebrated NAV pros, present enough facts to make the book worthwhile reading. Mark's long running history with NAV is guarantee to that, even though, I have to confess, I had to get used to his English phrasing. But it surely did not stop me from reading!

One of the things for which I will be frequently referring to this book in the future are the schemas. It has been a public secret for ages that one of NAV's major flaws in (technical) NAV documentation was the schematic representation of the various functional areas in NAV, i.e. the (almost) total absence of it. On this subject alone the books has filled a major gap.

The numerous meaningful and very useful (code) examples should also be mentioned; to be learned from by any newbie developer, to be used by experienced ones.

One of the few off-topics, and I honestly hadn't expect anything about it, nevertheless is "Testing". As Mark himself writes (p 443) "Testing is probably one of the most important but under-rated tasks of application design". But then only spends less than a page on it. Another gap to be filled by PACKT?

Altogether BAD is great,

I guess now little over a week after returning from my summer vacation I am settled down in the normal mode again. "Work and get paid?", you're thinking.  

Well, yes, you're right, but that's not what I meant. Just simply getting back on writing a new blog item. Start thinking about it wasn't hard as during my absence my blog apparently got bombarded by a significant load of Russian comments. To be frank: I just treated them as spam as I unfortunately am not equipped with any understanding of Russian whatsoever.You know the load wasn't that abnormal, however that these all were in Russian (or at least that's what I think they were) was new.

Nevertheless these comments did not trigger me to write this post. It was actually today's statistics of my blog. Have a look.

Since my last post on Wed, Jul 14 2010 the number of hits had settled down to, say, about 70 hits a day with a bit lower numbers on the weekends. Busy as usual. But see what happened today! I hadn't written a new post and all of a sudden ... BANG ... "sky high".

No Russian comments I can tell you. I could not even trace any hits on any of my posts today ...

Any of you bloggers experienced the same?

Ever since, what in retrospect became, the final album of The Police, the concept of synchronicity has taken root in my every day conscious. Not something that is leading my 'way of doing' or whatsoever, but as some pair of glasses through which I observe life with amazement every now and then.

Scene 1

Yesterday evening. Two fellow NAV veterans. Me. On my terrace. Table and chairs. Coffee and apple pie. Hot water and autographed book. Discussion (among others) on NAV community. How some tend to keep things for them selves. How others tend to share. Wondering if the first mentioned are typically using the various forums as references for their daily work or not. Me thinking: nice topic for a blog post. Some other drinks.

Scene 2

Day after. Early-bird me alone in our kitchen. Sun at the verge of flooding in. Computer running. Browsing unread feed entries. Waldo's Select Role when logging into NAV 2009 RTC. tdoelman's Use of standard components in NAV implementations.

Do I need to say more? Need to write more?

O, yeah, of course one big thank-you guys:

THANK YOU!

This morning I received an update mail from Microsoft support on a technical incident that felt I had logged ages ago. To be honest: it's 3 months old, reported on April 13th of this year. A good old colleague is the Escalation Engineer (EE) on this, and as he handed off the issue to the Sustained Engineering (SE) team, he updates me on a regular basis. It's nice to have still these kind of interactions.

Well alright, as the bug has been sitting their for such a long period I dutifully browsed to the bottom of the mail, only expecting to see nothing more than an "issue is still worked on" kind of phrase. Well ... you are right: it wasn't the case. Surprise: I was presented a code suggestion to tackle the bug.  On the first glance my gut feeling wasn't positive and I can say: it makes sense most of the time. Investigating the code suggestion more closely  I was at the verge of shouting aloud: please, don't reinvent the wheel!

Changes in Service Documents

Without going too much into the details of the issue I should explain it just a little bit. The issue I reported concerns some Dutch local feature that had been implemented on sales and purchase documents and has been part of NAV NL as long as I can remember. My bug report is addressing the fact that this is not implemented on service documents. As you might recall the first version of the Service Management module did not have it's own documents but was using the sales documents. So the Dutch feature was there already. However when the dedicated service documents were introduced, we, at the Microsoft Dynamics localization team (GDL), had overseen this change and did forget to implement the Dutch feature on these documents.

Solution Suggested

So basically the whole thing could be solved by examining how the feature had been implemented on the sales documents and apply it to the service documents. More or less (haven't used that term for a long time): copy and paste!

BTW: on my initial report I even provided a short description on how it could be fixed. All in vain as the SE developer probably thought he had to invent the wheel and made his own (and wrong!) solution. For heaven's sake!

Basic Rules of NAV Development

One of the basic rules we taught in our Solution Developer courses was to use the NAV application as the main reference when building features. Apparently this story shows that still isn't common sense. So please, all you developers out there, please ...

... don't reinvent the wheel ...

... improve it!

.. unless you really need to build something (really) new.

Your customers are in need of a solid and sound solution, not a piece of art.

In our onward going strive to get our verticals as efficient as possible on the market we were recently discussing whether we should continue our own Links feature or should abandon it and fully adopt the standard NAV version. One of the arguments against standard NAV is the simple fact that users are not able to personalize the Links window, both on Classic and RTC, while they can in our solution. As this also seemed in conflict with standard NAV behavior we considered this a bug and decided to log an incident for it: incident 9717916 (for details see How to Customize the Links FactBox?).

Bug or By Design

Some bugs are clearly bugs and some are in the gray area where you could consider them to be "By Design". And this is exactly how the MS support engineer looked at the issue. Long story short: there was nothing to fix from his point of view and after a short discussion we agreed I could (and would! ) request this as a feature change through Microsoft Connect.

Voting

Although I have been using the tool for ages already, it hasn't been many times. And every time again it appears to me the tool is a disaster from a usability perspective. First I have to search for the right URL: I often just go to Partner Source (or even www.microsoft.com) and search for msconnect. And once I am logged on it feels I have to relearn the tool, every time again! Eventually, however, I always succeed, one way or another, to get my things done. So I got our Links issue logged as a suggestion (have a look here).

But then I wondered: in what way could I give some weight to this? Well, any user of the tool - having the right permissions for a specific product - can vote on an entry:

Then looking at the list of NAV suggestions it's clear that the vast majority of entries only have 1 vote in favor (and zero against). Which raises the question: who's actually using this tool? Have you ever used it? Did you ever vote on Microsoft Connect? It does not look to me many are ...

A Call for Action

So on my mibuso post for the Links issue I placed this simple "call for action". Apparently not in vain having 9 votes so far.

Note

1. Although it seems users can personalize the Links window on classic, i.e. reorder, hide or show columns, these changes are not saved to the .zup file. As soon as the user closes and reopens the window it's back in the initial state.
   
   BTW: ever noticed that you cannot filter (or sort) on this window? Buttons, menu items and shortcut keys are not working.
2. Microsoft Connect can only be used be registered users. To be honest: I do not know what the policies for this are as I cannot recall how I got registered. Might be based on the same credentials I have for Partner Source.

Update

Yesterday (July 6) Søren Nielsen published his post Table 2000000068: Record Link – almost great!. Worthwhile to have a look at and also vote for his MSConnect entry!

As I am preparing some RTC demos I had been roaming around on Partner Source for some good ideas and had a look at the demo scripts. I down loaded various of them including some PowerPoint presentations like the Introduction to NAV 2009 PPT. The link says it's a .pptx file, but once down loaded it shows as DemoScriptIntroductionPPT.zip. Opening this .zip file I found myself looking at a whole bunch of files:

So what to do with that?

As I recalled it was not the first time I ran into this issue so I logged an incident on it and within 24 hours I did get the .pptx file! And this morning I even received a second one through another MS channel. The latter also explained what I could have done myself:

You can simply rename the file extension that you downloaded on Partner Source (from .ZIP to .PPTX) and you will be able to open it with Microsoft Office PowerPoint.

I had tried a similar thing, but on the some of the files in the .zip file, not the .zip file itself.

As said before: a child can do the laundry!

Note

Probably this applies to many more files on both Partner and Customer Source. I wonder why MS does not use the .pptx extension for these files or writes some kind of instruction for the user that she knows. Or am I the only blond guy?

BTW

I have never dived into PowerPoint file formats, but seeing this should I consider a .pptx file being indeed some kind of .zip file?

When I open my blog control panel the dashboard part shows statistics on the number of recent views and recent posts:

Just now I noticed that my post on MS Test Manager 2010 & NAV is my first one hitting a thousand. So one big thanx to all my readers!

BTW

... dynamicsuser.net home page lists an excerpt of all blogs. The number of hits displayed always tends to be lower than the numbers on the dashboard. Anybody a clue on that?

For the second time in little over a week I ran into the same situation where, after updating the CustomSettings.config file and restarting the NAV Server, RTC was still connected to the previous database. The first time this happened I eventually got RTC connected to the right database by restarting my computer.

As I didn't want to restart everything again today I decided to pick this up a bit more intelligently. So I searched the forums but, although I came across various worthwhile info, it did not provide me the right hint. So I wondered how I had done this before. I could clearly recall that I had been changing reference to databases like this before and I was quite sure that simply restarting the NAV Server was enough. And then I realized that only recently I had configured my default NAV Business Web Services to automatically start up.

"Might it be," I asked myself: "that both servers should be stopped before the updated CustomSettings.config file could take effect?"

Trial and Error

A simple trial of this thought proved me wrong, oops, sorry: right! I stopped both services and after that restarted them again. Aha.

Some More Background

To better understand this all I had a look in the Microsoft Dynamics NAV 2009 Developer and IT Pro Documentation. Specifically these sections gave me some better understanding:

1. Microsoft Dynamics NAV Web Services
2. Configuring Microsoft Dynamics NAV Server

Apparently both NAV Server and NAV Business Web Services are linked to each other and if either one of them is still running the original config file is still 'active'.

Last week I attended an internal event where during one of the break-out sessions my younger colleague Andreas Zippel did a very good presentation on RTC arousing quite some enthusiasm in the group. Worthwhile mentioning is that he only recently started working on RTC!

Already working with RTC for a couple of years I was also touched by it all, not in the least due to the fact that I even learned something new. I have to confess I was quite surprised I hadn't noticed this feature before. Especially seeing today that it was already announced on some of the NAV 2009 pre-release presentation (see for example Marq's and Waldo's blog). Why write about it as it is already known? Just the simple fact that probably there are more shortsighted like I apparently am.

Shortsighted?

Yes. I have been customizing a lot op pages over time and never ever had noticed it was there. Just have a look at this picture:

See the encircled button? Just push it and a freeze pane marker will be inserted after the selected column name in the right list:

Now clicking OK will effectuate the feature and now I can (horizontally) scroll through the customer list while the No. column stays fixed!

As we say over here: a child can do the laundry.

Today I was reading an interesting internet article by Andy Jordan called Quality, Not Testing. Not in the least because of the comments added to it.

As Jordan writes, quality and testing "are ... very closely tied together" and as such, I would say, we tend to use them synonymous to each other. But they are clearly not, is Jordan's plea. Needless to say I fully agree with him. You can argue about the details of his article (see the comments!), but the basic thread is right in the bulls eye and gives us the opportunity to evaluate the way most of IT projects tend to position quality and testing. In most cases unconsciously.

Want to read more on this theme?

Have a look at this blog post of mine ...

Wanting to prepare a nice RTC demo I recalled that freddyk had built a interesting example of how to manipulate NAV data through Excel. So yesterday I sat down searched for the relevant blog posts and ... started reading:

• Edit in Excel
  • Part 1 (out of 4)
  • Part 2 (out of 4)
  • Part 3 (out of 4)
  • Part 4 (out of 4)
  • bug fix and R2
• Edit in Excel R2
  • Part 1 (out of 2)
  • Part 2 (out of 2) – the final pieces

At first glance I saw a lot of, probably very useful, code and background info, but at this point in time too much noise for what I wanted to reach. Just getting the darn thing working. Freddy, you indeed succeeded in getting me to read it all!

Plug-and-Play?

Following my GUT feeling I decided to crawl through the last post - i.e. Edit In Excel R2 – Part 2 (out of 2) – the final pieces - but I could not find a simple plug-and-play how-to and was not sure if just acting on these last 3 sections was enough. That's when I decided to also crawl through the rest. Well, it surely made sense to read it and get a better understanding of it all, but still no clear plug-and-play scenario at hand, eventually returning to where I started: these last 3 sections.

All [...] is captured in the NAVEditInExcelR2.msi – which is the output from the Edit In Excel Setup project. Running this .msi on a client will check pre-requisites, install the right DLL’s, register the COM and you should be good to go.

[...]

The Server Setup program actually just needs to place the Client Setup Program in a ClientSetup folder and the .fob (NAV Objects) in the ServerSetup folder;

There are no pre-requisites, no actions no nothing – just copy the files.

After Copying the files on the Server – you need to import the .fob, run the setup code unit and you should be good to go.

Note, that this requires ComponentHelper1.03 (which you can read about here and download here) to run.

The source for the entire thing can be downloaded here and the EditInExcel Demo msi can be downloaded here.

So I did set off and based on this created my own how-to. Here we go.

Steps

1. Get ComponentHelper1.03.zip here
2. Extract and run ComponentHelper1.03.msi; this will place following files (in directory)
   1. NAVAddInHelper1.01.msi
      in C:\Program Files\Microsoft Dynamics NAV\60\ClientSetup
   2. ComponentHelper1.03.fob
      in C:\Program Files\Microsoft Dynamics NAV\60\ServerSetup
3. Run NAVAddInHelper1.01.msi
4. Import ComponentHelper1.03.fob into NAV database
5. Get EditInExcelDemo.zip here
6. Extract and run EditInExcelDemo.msi; this will place following files (in directory)
   1. NAVEditInExcelR2.msi
      in C:\Program Files\Microsoft Dynamics NAV\60\ClientSetup
   2. EditInExcelDemo.fob ComponentHelper1.03.fob
      in C:\Program Files\Microsoft Dynamics NAV\60\ServerSetup
7. Run NAVEditInExcelR2.msi
8. Import EditInExcelDemo.fob into NAV database
9. Run codeunit SetupComponentHelper (66009) and close WebServiceURL window
10. Run codeunit SetupEditInExcel (66029) and close dialog
11. Compile Pages 22 (Customer List) en 27 (Vendor List)
12. Run RTC
13. Select Customer List and set filter
    
    
14. Select Actions > Edit in Excel
15. Click OK in dialog
    
    
16. Excel will open
17. Click Install in dialog (first time only)
    
    
18. Now Excel will open with Customer data, f.e.
    
    
19. YES!

Possible Errors

When selecting Actions > Edit in Excel the following errors may occur

1. Error Message:
   
   
   
   Reason:
   codeunit SetupComponentHelper (66009) was not run
2. Error Message:
   
   
   
   Reason:
   Service "Microsoft Dynamics NAV Business Web Services" is not running

More ...

Of course freddyk posts are the basis to this all, however here you can find a nice video demo.

One technical incident we posted to MS some weeks ago which might be of interest to you. Initially I posted it on mibuso.com, but did not get a satisfactory reply on that. You will however find the workaround suggested by the MS engineer to me also on this post as she later copied it on this post.

Issue

Our add-on I-Fresh has a generic feature that by default opens certain forms as not editable, to avoid that users accidentally start typing and modifying any data. Simply pressing a button enables the user to bring it into edit mode. Getting I-Fresh RTC ready it became apparent that we needed to redesign this feature as it could not be transformed straight forward. Instead of keep-on-trying to get it transformed one way or another, we wanted a different approach, recalling the fact that pages can be opened in either View or Edit mode.

Likewise the Customers list place - view mode:

Likewise the Customer Card task page - edit mode:

Solution

Logically we thought that this would be our solution: make sure those pages open in view mode and by using the Action or Contextual menu the user would be able to bring it from view to edit mode:

But we could not find a standard way - a property or C/AL method - that would allows us to open, for example, the Customer Card task page in this view mode. Although we were quite sure that it could open in view mode as running it from the Object Designer does open it in view mode:

And ... the page can than be brought into edit mode through the Action menu!

Workaround

After reporting our issue, within 1 day (!) we did get a proper workaround as indeed the RTC platform currently does not support this altogether.

Here it is, copied from our service request:

... we found a workaround, this I tested out using Windows Scripting Host Automation and SendKeys in the OnOpenPage Trigger to toggle the Editable Property for the Page and it worked.
However this is NOT SOMETHING I CAN SAY MICROSOFT RECOMMENDS or have tested on a larger scale.
Anyway, this is a sample of what I tested.

...
Declare WshShell as Automation Variable for 'Windows Script Host Object Model'.WshShell
In OnOpenPage Trigger:
...
IF ISCLEAR(WshShell) THEN
  CREATE(WshShell,FALSE,TRUE);
WshShell.SendKeys('^+V');//Ctrl+Shift+V

here the command for the Edit:
WshShell.SendKeys('^+E') //Ctrl+Shift+E

And yes, we tested it also and it's working OK. Thanx Microsoft! Thanx Ariella Benchetrit!

Future

Nevertheless, I was not fully satisfied so, although very much pleased with their effort so far, I could not just live with the fact that it's not simply supported and so I decided to push back still. To be honest I had no high expectation, but I just wanted to give off some kind of message as I was:

... still a bit flabbergasted as running a page from the object designed (see my repro steps) the page is clearly launched in View mode (and the user can change it to Edit mode); so somehow NAV supports this.

 And yes, no real solution, but a promise, for whatever it is worth:

... this is in feature requests list and could be included in next NAV 7

Note: could! Help me hope it will.

I am sorry, but I will keep you waiting for a week or so as I will be on holidays enjoying the Southern French atmosphere. Hope the weather will not keep me from doing that. Au révoir.