The Northwind 2 Project (2 Viewers)

Status
Not open for further replies.
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.
 
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.
 
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.
 
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?
 
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.
 
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.
 
All of the comments and suggests are interesting, but they would have been more useful 9 months ago, during the design phase. ;) :)
 
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.
 
........., 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.
 
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.
 
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.
 
Just to go back to Northwind Basic, and Northwind Advanced - the thing that struck me was just that I would expect NW Basic to be a subset of NW Advanced, so that a NW Basic user would find everything he understood still worked just the same when he moved up to NW Advanced.

This was going to be a longer reply, but I've just deleted most of it.

I just think a new database programmer should start with something much simpler than a business application. I imagine a lot of power users need business applications, and think they can build Access applications as easily as they can use Excel, but Access or indeed any multi-user business system can't be developed without a lot of thought in my experience.

It's like the Pharmacy software that @Pat Hartman mentioned. When you build it wrong from the start, it's very difficult to get it right afterwards, and they probably have now got 100's of clients all using the same software. Maybe Pat's pharmacy software has "reminder" settings to send reminders at a certain time before the prescription expires, so it may just be a minor training issue, but you would probably need to have a very close relationship with the practice to be allowed to get involved.
 
In a business application, once the users have moved beyond the training/learning stage, it has little if any advantage.
But it is not "once"! This might be true for users working with that application all the time. But for users, which use such an application or certain functionality within it only once a week, once a month, or even once a quarter, the "learning stage" starts anew every time they use the application/functionality.

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.
I agree with this for my own, personal user experience. However, I think it is questionable to assume this to be a general rule applying to all users.

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.
I don't understand your point. The amount of space a drop down control in the ribbon consumes is not significantly different from the amount of space required for a classic drop down menu item.

How much space would you save with this being a classic menu drop down?
1675676461484.png

50 pixels vertically, maybe 70px?
[Edit] I measured it. It's slightly more than I thought: ~5px per item, 88px total for the drop down displayed in the above screenshot, including the space for the larger ribbon button. [/Edit]
And actually, I prefer the slightly more generous spacing between the items with ribbon drop downs.
 
Last edited:
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.
One of the key things we learned in developing this version is just how important it really is. Watch for it when it finally becomes available. I will go so far as to predict that using an AutoExec macro the way one of the other team members implemented it will become a best practice at some point, with regard to the question of Trusted Locations.
 
The worst software I am forced to use on a regular basis is the website for my online pharmacy. Their main display of my "active" prescriptions shows TWO prescriptions. Think about the bloat and wasted space. But they have a very prominent and unnecessarily huge header. I should be able to see a dozen, not that I need them but since they persist in showing old stuff, that would be rational. For example, my dentist gave me antibiotics last year and that prescription still shows and I can't even hide it. It has no refills so will never be used again. And then I see a prescription that had one refill left when I switched from Walgreens to ExperssScripts last year but is still showing and I can't get rid of it either or hide it even though I transferred the prescription last year and probably couldn't refill it at Walgreens if I wanted to. However, they will let me hide an active prescription with pending refills!!! Go figure. Then they send me emails months before they're going to refill something. Seems like the day after they fill a 90 day supply, they start sending me emails preparing me for them to refill the prescription 89 days in the future. But of course, just in case someone reads my emails or looks over my sholder, they refer to the prescription as "P" and since I have two P's, I have no idea what they're talking about. At least if they numbered them, I could look and see they are talking about the P that is #1 or the P that is #3. So much stupidity in so little space. I've tried to talk to people who might care and even offered to test for free but no, they'd rather just annoy me several times each month.
Very briefly, my bank did something similar with their "redesigned, IMPROVED, really cool" download page. It used such large icons and text that you had to scroll two pages to select the download options at the top and the submit button at the very bottom. Even on a high resolution monitor! My guess was that they designed it that way to accommodate smart phones, where those enormous buttons fit under one fingertip and scrolling is expected.

Fortunately, enough people complained that they launched a "redesigned, IMPROVED, really cool and actually functional" version fairly quickly.
 
Our own personal thought, needs and opinions aside, what a great accomplishment! Kudos to you and everyone else involved and let me say thank you very much!
 
Status
Not open for further replies.

Users who are viewing this thread

Back
Top Bottom