The Joel on Software Discussion Group

In case many of you not heard, the next version of ms-access will have web creating ability.

I been playing with the access beta preview and I made a video of an access application of mine. You note halfway through the short demo I switch over to running the application in the browser.

http://www.youtube.com/watch?v=AU4mH0jPntI

It really is quite a nice little design system. You build/test/design/run the application on your desktop. You don’t have to install or setup any kind of server parts to start the development process. You then have a simple publish button and the whole application is pushed up to the web server.

Using a rich client and not having to deal with database server, web server, browser scripting etc makes for quite a neat application development approach.

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com

Pretty cool.  I remember wishing for this way back in 1999.

I haven't used Access in a long time, but recently I decided to try it out for a small reporting project as no alternatives were available.  I was kind of shocked -- It takes only a few clicks to go from the shinny Office 2007 UI to reach way back into the past to dialog boxes and forms that appear to come right out of the Windows 3.1 era.  Has that improved at all in the next version?

Yes. If you looked at the video link above, I start out in the access client. Note the round or beveled buttons with hover  colors and effects.  So we now can build web style interfaces.

This type of UI building and themes is supported for BOTH client applications, or when you build 100% web based applications using ms-access. In fact, you can mix web and client forms in applicaions for 2010.

On the other hand, if you turn themes on in 2007, then your screens should not look so old. Throw in the ribbon, then in fact even your access 2007 software can look better then a lot of desktop software you see.

No question that 2010 is REALLY nice improved in this area, but applications in 2007 can look really nice. Here some screen shots of access 2007 application that is very slick:

http://blogs.msdn.com/access/archive/2009/05/22/i-love-good-old-county-fairs-customer-case-study.aspx

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com

That's pretty slick looking stuff.  Feature wise it's on a par with Delphi 6, but looks wise it's up to the minute slick, based on the screenshots you showed.

If the magic is not done by Silverlight, it must be some sort of javascript AJAX translator/compiler.

Silverlight might be an add-on, but it allows you and Access to customize on top of it much easier . It's more and more popular anyway.

Javascript-AJAX combo can do fancy stuff but with lousy noodle code here and there and hard to tweak. So anything you need to tweak you go back to ACCESS2010 , make the change and hope it can "compile" to the right javascript.

Yes, behind the scenes it is all ajax. I tested the application running on ubuntu + Firefox and it works 100% perfect.

Here is another video posted on channel 9 that shows another access (web) application running in the browser. They are nice…

http://blogs.msdn.com/access/archive/2009/11/12/the-access-show-recap-of-sharepoint-developer-conference.aspx

>So anything you need to tweak you go back to ACCESS2010 , make the change and hope it can "compile" to the right javascript.

Well, you don't have to compile on the access side, you just make your change and your done. You develop interactive here. It still a true rad environment with bound forms that always made access so easy to use.

Once you changed the form (or its code) and are happy with the way the form runs, then you whack "sync" and the changes go up to the server. 

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com

>Once you changed the form (or its code) and are happy with the way the form runs, then you whack "sync" and the changes go up to the server.

That's what I meant about "compile/translate": from Access2010 to Javascript/Ajax.

Sure, easy form stuff won't have any problem, but if you have some "fancy" form flows or controls not having a built-in ajax control you are out of luck (e.g. fancy calendar/file uploader etc.) because it doesn't know what to translate.

Silverlight is way more sophisticated than Javascript/Ajax, and  supports all major browsers on both Windows/Mac (I tested both.  Linux only supports the older Silverlight because of mono not updating to latest)

I don't know why Access decision makers didn't support their own good stuff.

>if you have some "fancy" form flows or controls not having a built-in ajax control you are out of luck (e.g. fancy calendar/file uploader etc.) because it doesn't know what to translate.

Well, there is a date picker. And, there is even a web control that you can insert into forms. And, attachment fields do allow uploading of files (all with little if any code needed).

However, in a nutshell you are limited to the features you have. On the other hand, if you look at the video I made, you see a time picker I created with some listboxes, and the results are nice.

So, you can't build something that will not translate here.

The way this works in access is that you lock-down a form as being web compatible. When you do so, you are automatic restricted to a set of features that will allow the form to be published to the web. You not be allowed to build or design any part of a form that will not work with what is now called "access web services".

So, sure, you might be restricted feature wise, but the result and tradeoff is a fast and simple to use RAD tool.

It is brilliant and simple design since you get to develop on the desktop with a RAD tool. You don't need to learn a bunch of server based languages or database systems. In fact  you can do the development process 100% on the desktop without any server parts at all.

You build, and then hit the publish button and the result is a very scalable application with a true multi-teir design. So you can't build a form inside of access now that is not compatible with access, and the same goes for when you build a web form inside of access. When you done, it will publish.

So the easy to use desktop development model is still used here including things like bound forms and sub-forms.

A simple few clicks and the application will publish up to the server side. It is darn cool, and very easy…

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com

(Earilier access can already do some easy web translation but it's too lame and get canceled, you may know that better than I do).

RAD is good but it's old story. RIA is the way to go. 

RAD/Easily publish/convert/translate to web are good. I'm not even arguing that.

My argument is: Why the decision maker chose Ajax/Javascript instead of their own rising superstar "silverlight" for this job?

MS treats Silverlight as Flash killer, and it is version 3 now. It will support linux & mobile smart phones as well.

so many things Ajax/Javascript can not handle well or easily.

Silverlight can run full screen mode and access local computer resource much easier. (You can not easily use Javascript/Ajax to tweak page preview  for example.  Even google book reader uses Flash doing the similar job)

I said "fancy calender", you argued with "date picker".  Ok, I will detail it a bit, a "fancy calender" scheduler like outlook's which can pick date and schedule tasks and arrange meetings. It's common to have it these days. And it's not a "wow" feature like 10 years ago when Access VBA/RAD reached mass market.

With much richer internet support/better user experience & more and more popularization, I really don't see why the decistion maker goes another way.

Especially for the end user deployment,  it's the same , in term of your "whack sync".

one more thought:

If this web publsh engine uses silverlight instead of ajax/javascript as the result, It's much easier for a developer add features to the end result.

Ideally, It will work like this
Access VBA/RAD creates form,  user hits "publish", a silverlight package created. XCOPY it to web server. Done.

If any new "fancy control" need to be added, Just use .NET/Silverlight express to customize and add it.

Ajax/Javascript can not do this. If you ever read the MS automatically generated javascript/Ajax you will know.  It's big mess NOODLEs and not suppose to do any maintainence on top of it.

Well, they likely choose this result so you don't need silveright. The idea here was to create something that runs in a browser with no activeX or any kind of 3rd party installs needed.

So the design goals were likely simplicity, and support of multiple browsers running on multiple OS's here.

Everything is a tradeoff here, and I fail to see why a high performance graphics rendering system like silverlight should be used for displaying what amounts to nice forms in a browser?  I mean, the underlying technologies they are using is the .net xaml (zammel) stuff, and does a fantastic job of rending forms as you seen in those demos.

I suppose they could have used silverlight, but the benefits of doing so likely would not outweigh the need and ease of running the application on your Smartphone or in different browsers without first having to download and install something. 

While silveright might be supported on SOME mobile devices and browsers, it still really not needed in this type of application, so the benefits did not outweigh the downsides.

So, the only answer I can think of is this was an very intelligent and well thought out engineering decision.

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com

or maybe when the Access 2010 project started, Silverlight was still 1.0 (2007) and nobody knew where it would go.