The Northwind 2 Project

[GPGeorge]

Anything new on this?

Yes and no. The Starter version is essentially done. The Dev version will be done soon. We can't predict a completion date yet.

 

[gemma-the-husky]

I haven't noticed this thread before, and clearly the project is well advanced. In any event, I am probably not the target user now.
Just generally, I struggle to see what might be in a Northwind "lite", compared with a Northwind "full".

If the "lite" version doesn't include, say, inventory management or change auditing at all, that would make sense, but it would confuse me if the "lite" version didn't implement a common feature in the same way as the "full" version.

If you want different levels of complexity then you could just add setting flags to the "full" version to deactivate advanced or optional functions. That way you only needed to develop and maintain one version of Northwind.

I think it would be most confusing for Northwind itself to come in 2 versions, each doing a particular function in a different way. It also adds difficulty for the development team, as you then have to maintain 2 versions of Northwind going forward.

As an example, in my early days I really struggled with a CD database (may have been an MS sample) that showed track listings with times, and an overall CD total time. I was trying to follow how the total time was derived, and I just couldn't. In fact it wasn't derived at all - it turned out to be a separate field manually entered. This really confused me at the time, as it broke what I understood to be normalisation rules.

 

[sonic8]

If you want different levels of complexity then you could just add setting flags to the "full" version to deactivate advanced or optional functions. That way you only needed to develop and maintain one version of Northwind.

You meant "just add setting flags to the "lite" version"?
I think, this would be counterproductive. My understanding is that the "lite" version is meant as sample/reference database for beginners.
If this version would also include all the more complex code plus feature-switches to enabled/disable the complex function, it would fail in its goal to be a simplified version for beginners.

 

[GPGeorge]

You meant "just add setting flags to the "lite" version"?
I think, this would be counterproductive. My understanding is that the "lite" version is meant as sample/reference database for beginners.
If this version would also include all the more complex code plus feature-switches to enabled/disable the complex function, it would fail in its goal to be a simplified version for beginners.

I couldn't have said that better myself. But I'll elaborate anyway.

We have invested many months of work in planning, designing, building, documenting and currently testing both versions. "Starter" is, as the name suggests, intended for the person opening Access for the first time and asking themself, "What can I do with this application?" We created a sound data model that is about as simple as we could justify it being, while following good relational table design principles and naming conventions. We include a lot of tools to explore concepts and where and how to find them implemented in this Starter Version. For the most part, it employs "out of the box" functionality--exactly what new users should encounter when they first use Access.

The Developer version is, again, as the name suggests, for junior developers who need to explore more complex data models, programming practices and methods, and interface design strategies, including the ribbon. It is for those with some experience with Access who have decided to take a more serious approach to that work and want to adopt more professional methods.

It is important to note that neither version is a "template" for any specific business. While the NW2 applications will be distributed through the template mechanism, they are not intended to be used directly as templates, rather they are learning tools.

You could not drop them onto a computer, change a few names and run a business. There are too many variations possible in any business. All of them could be justified by a different set of business rules.

To offer one simple example: the difference between a logical and a physical inventory. In a logical inventory--say a booking system for airplane seats--it is possible to end up with negative inventory because the business rules permit over-booking a flight in anticipation of some travelers being no-shows. That's not the case with an inventory of bicycles. You count them in the warehouse and that's what you have. You can't process an order for a bike you don't have. You have to handle that a different way. Trying to implement both in the same database application would be a feat of logic beyond the scope of our task. In a real world scenario, business rules determine that; we choose to implement one approach and acknowledge that there are many other options possible.

I do not think you really understand the complexity of trying to "flag" features to use or not use in a single accdb. But that's a moot point now anyway. Starter is very nearly done, Developer is in the final throes of testing and bug fixing. We're smiling again, just a little, in anticipation of being done.

 

[gemma-the-husky]

I meant the other way round. Develop the full version but allow some functions to be turned on/off to get a "lite" version. I do see that from the point of view of a novice this is probably not easier at all. Maybe the Northwind lite is complete different from Northwind advanced, but to me that makes it trickier. A tyro developer looks at Northwind lite, but might then be confused when Northwind full does not do the same as the lite version.

The seat booking system is a good example. You can have a system that both permits or prevents overbooking. It can allow orphan seats to be left or not. It can be made first come first served, or it could hold bookings for a temporary period. You could build some or all of these options into a system, and activate or deactivate them according to system flags. That's what I meant. Users configure their system according to what they need, but the developer just has one generic system capable of satisfying different markets.

The inventory management is a different issue, but you don't necessarily have to reject an order because there is no stock temporarily. You could allocate it to a back order in some way. Hence it might be easier to build an all purpose system that offers both alternatives, rather than end up having 2 different systems. Then other changes not related to inventory only need to be added once.

I know adding flags is complicated but it's complicated whatever you do, if you want to make a turnkey solution flexible to your clients.

 

[GPGeorge]

Spoiler: etc

I meant the other way round. Develop the full version but allow some functions to be turned on/off to get a "lite" version. I do see that from the point of view of a novice this is probably not easier at all. Maybe the Northwind lite is complete different from Northwind advanced, but to me that makes it trickier. A tyro developer looks at Northwind lite, but might then be confused when Northwind full does not do the same as the lite version.

The seat booking system is a good example. You can have a system that both permits or prevents overbooking. It can allow orphan seats to be left or not. It can be made first come first served, or it could hold bookings for a temporary period. You could build some or all of these options into a system, and activate or deactivate them according to system flags. That's what I meant. Users configure their system according to what they need, but the developer just has one generic system capable of satisfying different markets.

The inventory management is a different issue, but you don't necessarily have to reject an order because there is no stock temporarily. You could allocate it to a back order in some way. Hence it might be easier to build an all purpose system that offers both alternatives, rather than end up having 2 different systems. Then other changes not related to inventory only need to be added once.

I know adding flags is complicated but it's complicated whatever you do,

if you want to make a turnkey solution flexible to your clients.

We don't expect it to be "a turnkey solution". And that is exactly the point I was trying to make when I said it's a demonstration of techniques and approaches, not a sample database to use for whatever purpose you might have in front of you at the time.

As you said yourself, there are many options possible. Trying to implement multiple sets of tables and multiple sets of modules and multiple sets of forms for "different markets" in a single accdb? No, that is well beyond the scope of this project.

 

[Cotswold]

Why not get rid of the pointless and screen space wasting ribbon? Go back to the standard menu. From my experience it appears there is only a tiny number of developers who add ribbons to their applications. Most don't use it because it adds nothing to their developments. After all who wants to lose 18% of their vertical screen with no real benefit?

 

[ebs17]

Do you know Ctrl + F1?

 

[arnelgp]

Go back to the standard menu.

retro look? i thought it was modern looking? the "in thing" right now is the Ribbon.

 

[Gasman]

Do you know Ctrl + F1?

I didn't, so thank you.

 

[Pat Hartman]

do not think you really understand the complexity of trying to "flag" features to use or not use in a single accdb.

In my applications that are sold to the public, that is exactly what I do. The "off" setting usually just doesn't display the unpurchased options on the menu or in some cases, hides buttons on a form that would otherwise lead to them. Sometimes I leave the option visible if I think they will change their mind and just tell them they can't use it.

 

[sonic8]

Why not get rid of the pointless and screen space wasting ribbon?

Whether you or anybody else likes them or not, Ribbons are an integral part of Microsoft's own MS Office applications. Any demo/reference application showcasing how to build applications for the MS Office platform with Microsoft Access should include a demo on how to work with the Ribbon as a developer.

Go back to the standard menu. From my experience it appears there is only a tiny number of developers who add ribbons to their applications.

My own experience regarding the prevalence custom ribbons in Access applications is similar.
However, in my experience the number of applications using customized standard menus in the past was only slightly higher because it was easier to use them.
Even if this would be different, a modern show-case application should focus on the current recommended UI guidelines by Microsoft, not on deprecated UI technology, now hidden in a sub-section of the ribbon.

After all who wants to lose 18% of their vertical screen with no real benefit?

Showing UI controls in a context sensitive, visually grouped and structured way is a "real benefit".
My own experience/opinion: For applications I was intimately familiar with, the ribbon was indeed a stark regression. However, for applications I rarely use, the ribbon is many times more intuitive, helpful, and user-friendly than a classic menu.

 

[Pat Hartman]

Any demo/reference application showcasing how to build applications for the MS Office platform with Microsoft Access should include a demo on how to work with the Ribbon as a developer.

If MS thought they were so important to the developer, they would have included a tool for the developer to use to build them

My problem with the ribbon as well as the old menus is that with each new release, features move to some other spot in the interface just because someone had a "better" idea.

 

[GPGeorge]

In my applications that are sold to the public, that is exactly what I do. The "off" setting usually just doesn't display the unpurchased options on the menu or in some cases, hides buttons on a form that would otherwise lead to them. Sometimes I leave the option visible if I think they will change their mind and just tell them they can't use it.

Yes, I don't mean to imply you can't do that in a production database you deploy, but the objects remain in the accdb, and as you say, might be enabled at some point. NW2.0 is quite different. It's intended to be wide open to discovery and exploration.

In the case of the NW2.0 project, leaving features and functions in an accdb to be discovered by Starter developers would be confusing at best. The point is to create an environment in which a new user can experience Access functions and features, and see how they work, without having to wade through advanced features they happen to discover in forms, tables, and especially VBA that isn't "implemented" for them.

Trying to make them totally undiscoverable would be a bridge too far for a template. Besides, our goal is to deploy them in 2023.

 

[Pat Hartman]

I happen to agree with you that separate databases are best in this situation. No point in confusing a novice with options. I'm sure you've gone with embedded macros for the learning version because that is what MS wants novices to use and hopefully, macros are non existent in the other version.

 

[GPGeorge]

All of the comments and suggests are interesting, but they would have been more useful 9 months ago, during the design phase.

 

[GPGeorge]

I happen to agree with you that separate databases are best in this situation. No point in confusing a novice with options. I'm sure you've gone with embedded macros for the learning version because that is what MS wants novices to use and hopefully, macros are non existent in the other version.

We kept the AutoExec macro.

 

[Cotswold]

........., the ribbon is many times more intuitive, helpful, and user-friendly than a classic menu.

Whilst I can see that the ribbon may be considered as more intuitive by some. In a business application, once the users have moved beyond the training/learning stage, it has little if any advantage. Screen space is always at a premium and more is better than less. As long as it is well designed and clear, more detail on a smaller number of screens usually makes a better system.
As an extreme example banking software will often require three screens for access, when everything could so easily be on one.

 

[gemma-the-husky]

I find the ribbon uses too much vertical screen space. I actually use A2003 menus and make them available through the add-ins. You can easily have a dozen options in a drop down menu in a very small amount of screen space, which you can't easily do with a ribbon.

For much the same reasons I use A2003 switchboards, which I believe are more flexible. I can easily have many more options on a page (30), and I can leave selected options blank to make the option grouping more clear. I didn't really understand the action macros (is that the right term?) in the newer versions of the switchboard, and never bothered with them as a result.

The autoexec macro is like gold dust. Its far easier for a slick interface than trying to build code into the startup form. Please never drop it.

 

[ebs17]

Design needs space to unfold. Some prefer to look at colorful things and pictures, some just want to work in a spartan environment. With that in mind, you can turn off the ribbons and offer a few dozen context menus as an alternative.

Something like that will hardly be the content of a general learning database. I would have expected this one to discuss the use of lookup fields in tables correctly and in a practical way, i.e. to advise against it straight away.