Friday 27 July 2007

"Do you have a .net version?"

A reasonably common question we get asked these days in tender documents or over the phone is "is your product written in .net?" or similarly "do you have a .net version of your software?". At this point I bite my tongue, take a breath and try to find out exactly why they've asked such a ridiculous question.

Do they understand what they're asking for? Usually not. A .net "version"? As if we have a normal version AND a special .net version?

At what point did .net become a selling point for software? At what point did .net leave the workshops and magazines and conferences and become something that customers actually believed was a feature? At what point did software resellers start putting on their website "written using .net, Microsoft's latest development platform"?


.net isn't a new platform, it's a "framework" for developers. The end user wouldn't be able to tell if software was written in .net or Win32 because there is no difference to the end-user. There's nothing new in it, nothing fancy or magical, it's just a well-designed foundation for developers to work with. The same one that we as Delphi developers have been using for years. Microsoft brought together years of different technologies and brought them under one roof. Designed by the very man who designed Delphi's OO framework. Nothing new: just the old stuff, revamped and rebadged (oh yeah, with garbage collection added). It's for us, not them.

Another misconception from users/customers/managers is that it's something to do with the internet. I can see why, because the name .net is simply one of the most misleading names in software history. The "net" in .net is a misnomer. It isn't about putting your software into a browser, it's just a rewrite of the Windows development framework. ASP.Net allows you to develop websites, but so did ASP.

A post last year on the Delphi Developer's Group newsgroups asked "Has this whole .net thing been a marketing strategy by MS to boost sales of Visual Studio? Did MS decide Borland, Eclipse and others were encroaching rather too much on the developer tools market and in a brilliant coup de grace has shattered the competition?".

Someone replied, "The thing that annoys me is that .NET is now seen as the latest must-have".

I replied saying how customers are asking if we have a ".net" version and this was well-received as generally the sort of thing customers are asking about.


I'm encouraged, by looking at competitor websites, that almost none of them are developing using .net (or at least their system requirements don't state the .net framework). The more we fight it, the longer they'll have to leave Win32 alone. After all, MS aren't planning to bring the majority of their flagship products across either.

Thursday 12 July 2007

Business Case for upgrading Delphi

On July 6th, Nick Hodges blogged about a new wiki page he has created entitled the Business Case for Delphi. This is a great idea (admittedly not his own) and for a moment I thought he had stolen my thunder on a topic I've been meaning to write about myself. However, Nick's topic is about why Delphi should be taken on in the first place.

This is not that story.

About 6 weeks ago I wrote an internal document called "The cost & business case for upgrading Delphi". As I have stated before, we're using Delphi 6 here because it is stable, fast and I didn't need any of that .NET junk on my PC. Delphi 7 wasn't considered to be that great a leap from Delphi 6 and so here we stayed. Moreover, it's not just an upgrade of Delphi but also a reinstall of all the third-party components that one uses. And then the time taken to get your environment just right so it's intuitive. There just wasn't enough to make me move.

The first release in all this time that has really caught my eye and made me want to upgrade is Delphi 2007 for Win32. I downloaded a trial and loved it, it was the first time I'd used the new Borland Developer Studio IDE although I've seen it for years in the demos and tutorials. All the new IDE features (code folding, component palette searching, refactoring) made me want to kiss the screen, so I thought I'd put together a list of pros and cons as well as a price so that I could discuss it with the company.

The money wouldn't be the biggest hurdle I'd have to overcome - I'd need to explain why I couldn't move development forward for a particular timeframe whilst I ensured that every application, DLL, plug-in, utility, etc was recompiled successfully and working at least as well as it is now. And then, after all that, we'd be at a stage where the software works exactly the same as it did before I started.

"What, all that time spent and you end up with the same product?", I can anticipate hearing.
But you and I know that it isn't just about that. Time invested there means potentially time saved when we have a much better version of Delphi, an IDE with cool features which supposedly mean I can turn work out faster. Ah, I'm getting them back on side with that one.

So this document, which admittedly was very balanced and not at all as conclusive as I'd have liked (but I was being honest) went to the technical director who, predictably, said, "Doesn't really help either way, does it?". Which was fair. So I posted it on the Developer's Group newsgroups (a UK-based developer's group that we're a member of and that has a private newsgroup) to see what my peers could add to tip the balance. The result was frankly disappointing given that its members and regular contributors are well known magazine authors and conference speakers.

But then I received an email from one of the group's administrators who asked if she could include the document as an article in the next magazine as it would make an interesting discussion. I happily agreed although I had privately thought that if there was to be a discussion, it would have taken place on the newsgroup.

In the meantime, I wanted to discuss it here. I'm going to reproduce snippets of the document below to outline the salient points and then see what you have to add. Do you agree with the points I make, disagree with them, or have things to add to them? Can you tip the balance? My heart wants to move to Delphi 2007 with Software Assurance but my head is wondering if it worth the investment of time and money.



Why move?

When Delphi 6 was written, there was no Windows XP. We use third-party tools (JEDI) to allow our application to take on the themes supported by Windows XP and Vista. Whilst this particular example is free and the widely accepted alternative, my personal opinion is that the more we move away from third-party support (where Delphi offers the same solution) the better, as it enables future upgrades to be less troublesome.

For many of our third-party components, Delphi 2007 was not available at the time we purchased them. But, in a fortunate turn of events for us, Delphi 2007 fully supports any code written for Delphi 2006 (they called this a “non-breaking release”); this means that most of the third-party components we already own will actually work in Delphi 2007, because they were written up to and including Delphi 2006.

Other reasons to move are not necessarily end-user based, but developer based. In 7 years, CodeGear (formerly Borland) have added dozens of IDE enhancements that would make the life of the developer much easier. Many of these features result in writing faster code, which means things just get done quicker.

Why not move?

The minimum deployment platform is Windows 2000 and so any Windows 98/Me users could not use the software (according to CodeGear’s site, this hasn’t been confirmed).
Third-party vendors appear to continue to support older versions of Delphi (including v6) because so many users don’t upgrade to the most recent versions.

Note: after I write this, someone added a comment on the Developer's Group newsgroup that they have successfully deployed Delphi 2007 software on Windows 98 and Me with no special code.

It could take up to a month to get everything fully migrated across to the new version. This includes all the standard software as well as utilities and plug-ins.

Tuesday 3 July 2007

The moving Microsoft standard

When I was first brought into my company to port the software from Unix to Windows, Windows 95 was the latest OS and Microsoft were very proud of it. Although I didn't read any official literature from them at the time, I was already aware from my own use of Windows that there were certain standards to be maintained. Not standards as in quality (heaven forbid), but standards as in consistency. But then, I guess we know Microsoft's record on following the standard.

(Actually I just want to point out that I'm not a died-in-the-wool Microsoft basher, I actually think they have produced some outstanding software, but none of us get out of our chair to compliment people do we, we only complain. Even us Brits).

In "The Windows Interface Guidelines for Software Design" from Microsoft Press, there are sections such as design "consistency" and "forgiveness" and an appendix giving "common navigation...and shortcut keys". This was especially relevant as Microsoft were trying to allow the mouse and the keyboard to be used independently as opposed to having to use them in combination.

I built my software around these common ideas, which wasn't always welcome; Unix, you'll remember or no doubt know, used the [Enter] key for moving between elements on a screen; Windows started to use the previously underused [Tab] key, and left the [Enter] key as the default action key (usually pressing an OK button). This caused all sorts of uproar from our customers who moved from Unix to Windows (usually because their management had wanted them to, not because they'd wanted to!), and on one screen in particular where speed of entry was paramount, we were forced to allow the Enter key to reproduce the effect of the Tab key. It didn't take me long to find how to do this 10 years ago which led me to suspect many people were in the same position.

But I towed the line for the most part and argued the case that "this is how it is done in Windows", and ended the debate. The principle of keeping to a design standard to allow your users to feel comfortable with any software is a good one and although it certainly wasn't introduced by Microsoft, they did make an effort to let developers know it was expected.

So, how is my software doing 10 years on? Well, sadly, it's looking like a Windows 95 application, but given that is deals with mundane day-to-day enterprise tasks, no one is really complaining that the menus or the toolbars aren't covered in colour and pictures. However, this is often a hurdle for the sales pitch and it's laughable how many potential clients sit through our unique selling points or all the items that our software does better than the competitors, and then sit bolt upright when we show them a report with some colours on it, or a screen where a bit of text is highlighted. Usually followed by, "Ooh, I like that; can you customise those colours?".

But my gripe is with the consistency of keyboard shortcuts. And one in particular: Search. F3. Isn't it? It is on our software because in Windows and Office '95, F3 was always "Find...".

Well it still is in Explorer in Windows 2000, XP & Vista (it brings up the File search) and Notepad (brings up the text search). And it used to be in IE5 but in IE6 it brings up the "Search the Web" toolbar which is immensely annoying. Interestingly in IE7, it brings up the page search again like before IE6. Bit of a U-turn. In Windows Media Player, F3 launches the "Search for Media" dialog and in MSN Messenger, it puts the cursor focus into the contact search box. All "find" related.

What about Office? After all it is Office that is actually the one setting the design standards every two years or so, not Windows itself. In Excel, Powerpoint and Access, F3 does nothing, CTRL+F is required to launch "Find". CTRL+F goes way back so I'm OK with that but F3 could have been made to do the same seeing as it is sitting idle. The same CTRL+F keystroke is required in Word, but horror, F3 does something else! Something to do with Autotext that actually either just changes my document or puts a conspicuous message in my status bar that I usually miss.

In Outlook, F3 shows the little Find toolbar, so one out of 5 isn't bad. But wait. What if I'm reading an email and want to search for text in there? F3? CTRL+F? No. F4. F4? But F4 doesn't do anything in any of the other Office programs. And get this, CTRL+F forwards my email. And F3 does nothing so why couldn't they have used that?

This is actually an unforgivable inconsistency from a corporation the size of Microsoft that prides itself in the interoperability of its software. Especially when they have the gaul to produce books on how we should adhere to design consistency.

So now not only does my software not look colourful because I can't keep up with every release of Office, it now doesn't behave like the latest Microsoft software either. So my users are left having to remember the keystrokes for my software, even though I actually set them to MS standards 10 years ago. But then those same users are going to find different strokes even within the Office suite so they've got no hope.

This isn't really a rant just about F3, it's about Microsoft setting a standard and then moving away from it at the next opportunity. The Ribbon toolbar in Office 2007 has split opinion and I can't lend my support to either side because I'm happy with the Office I'm on. But it's a whole new paradigm that users have to get used to. From what I hear, most people like it once they get past the initial fear, but it's a lot to ask people to learn how to use your software, especially when you're the company driving the standard on your own OS. And for us developers to try and keep up, we have to licence the use of the Ribbon? You're having a laugh.

MDI is another concept that MS really pushed to the forefront and my 10-year old software is MDI to the core. They announced some years ago that they would no longer write MDI applications and no longer thought it was a secure model, which is why you now see Word and Excel, etc all open up a separate Window instance for each document/worksheet as opposed to them all being under one parent window like Office 95. Of course you can still switch between them from the Window menu which is a nice touch for those of us who should know better than to get stuck in our ways.

But the real thing that this is about, and what I wanted to ask you, is should we, do we, and how do we keep up with the look of the software. I fall in the camp that I want my software to look native to the version of Windows you're running. To that end, I use buttons that aren't themed in Windows 2000 but take on the common controls theme for XP and Vista. Same for all other controls. And I set my application font to the font of the OS when it runs, so it looks native and not at all clumsy. And in fact this works well, espeically in Vista. A Delphi 6 program running on Vista, still using the default MS Sans Serif font, looks very old. Even with theme support. Change the font to Segoe UI and bingo, it makes a dramatic difference.

However, not all controls are themed, toolbars being one. There isn't a difference between ComCtrl 5 and 6 for these. So that ruins the effect I was getting closer to, where my application doesn't look out of place. I don't want it to look like a Vista or XP app on Windows 2000 (which personally drives me crazy), but some of those controls just don't scale up to allow me to have it both ways.

And of course many people turn the theming off in XP and Vista and go back to Classic; so why should we subject them to the themed buttons when all they want is their old Windows back?

So how are you keeping up with the trends? Are you at all? Have you gone down the route of just designing software that has a look of its own in which case you are your own master, or are you trying to design it so that it fits in? At what point do you let the nice new buttons and other controls creep in, regardless of the OS?