I have only just looked at the NAV2009 Role-Tailored Client and I was about to post a huge rant about it as first impressions were utter disgust and amazement....
But I held off while I played with the Customise options ... however, my second impression is still pretty disgusted and amazed tbh!
My main gripe is that I cannot understand why everything is approx 1.5 times bigger than in NAV5 and putting myself in the Customers shoes for a second - I can't see an easy quick way to reduce the size of everthing.
Looking at Form 42 Sales Order as an example with NAV5 and NAV2009 RTC open side by side I can see that the boxes around all the fields in the RTC have become HUGE...why!?! There's no need.
This is a stupid and needless step backwards unless you are close to going blind..!
Please tell me there is a single setting somewhere which resolves this - otherwise I'll avoid it like the plague (unless I have a SPECIFIC reason to use the benefits of RTC - yes I know ALL about them so please no posts about that!)
Cheers
Comments
The RTC represents a different way of doing things. So I would suggest you approach the RTC with a fresh mind and forget what you know about the classic client.
For the record, I think the RTC sucks. But you have to respect the customer's choices.
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
So give it some time to grow on you.
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
I worked in ERP system il the laast 20 years, but I'm only 2 years old in Nav.
The 1st time i saw RTC i loved it. It's the best interface I never used in ERP system.
All my customers use it and they really love it.
It's easier and faster then the classic one.
I miss some functionality, like better color control, a litttle bit more control on positions and dimension of UI elements...
On developer point of view, page creation is much more faster and easier than form.
Factboxes are great.
New report too.
In Demo session, no way, RTC UI is the winner over all competitor.
For sure you don't have to think in a "classic" way.
I know it's non easy if you worked for a longtime with the classic version.... but i worked for longtime with char based mainframe interface....
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
http://dynamicsuser.net/blogs/mark_brum ... art-1.aspx
Yes, new customers like it over the classic client and it is more productive once you are used to the new shortcuts. I am using F4, CTRL Enter and F9 now for a while and it works fine.
As for the size, be honest... with the current laptop resolutions it is next to impossible to read and use the classic client, it is so small.
The performance is dreadful and there is no way the new RTC interface is quicker or more productive, it has just been dumbed down. Don't believe me - speed test - mouse vs experienced keyboard user, who wins? This isn't just teccy/dev talk either - I've seen end-users absolutely flying with "the old" NAV keyboard shortcuts.
really? seriously? well, as the advert says - I guess you "should have gone to specsavers!"
All this it's the 'future' etc stuff is all well and good and things always need to move on BUT ask yourself what the primary function of NAV is (an ACCOUNTS system) and then compare it to MS Office and ask yourself which is the most productive / similar package is it...
A) Outlook
Excel
I think that just about sums up why for most users this is a step backwards
Thinking further - aren't the speed issues also because of choosing option A not B above! Excel good, Outlook awful.!
Yes, object caching is dreadfully slow but once an object is in cache the performance is good enough for normal usage. I am convinced MS will fix this in either a hotfix or future version.
For batch posting the classic stack is about 300% faster but you can still use a NAS for this process.
My suggestion would be to start doing a full implementation with it and come back after this.
Most of the time these 14"CRT users in factories or warehouses are working in one screen the entire day doing one task often with bar code scanners.
Am I right?
What is the best solution for those users...
I would say either (1) the classic client, (2) a webservice or (3) a very basic page in the RTC
But definately NOT the complete RTC with rolecenters, factboxes etc...
And yes, Mark described it... in most cases, in production and warehouse, users needs only few specialized windows, which could be done in classic, RTC or Sharepoint or special application etc. easily... (and it is not problem to buy new touchscreen LCD for few bucks, and you do not need mouse and keyboard...)
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
Well, er, yes and no. Basically in the old days when you would just put up a native server on whatever server hardware a company happened to have and thus the implementation costs were just licence + consulting, it was possible to compete with those small accounting packages that haven't really been ERP systems, i.e. it was possible to have small and kind of "amateurish" customers (not a real enterprise, just an entrepreneur) who haven't yet have a real IT infrastructure, nor anything like an IT strategy, and so on. Projects around 30K EUR, competing with non-ERP accounting packages.
Now that the general infrastructure requirements of NAV are going upwards - SQL Server, with that a decent server hardware, modern screens and so on - these require a wholly different approach. It's being aimed at customers who have IT strategy, a decent IT infrastructure - who are generally bigger and more like a real enterprise. Typically ones who do have internal IT etc.
On one hand it makes my life as a developer easier - because these things tend to scare away exactly that type of customer who is the hardest to work with: the "amateurish" type for whom IT is just an ad-hoc tool and not a strategic asset.
But what I still don't like about it is that at the end of the day it means less sales. We can do without these kinds of sales, our company is doing well but not everybody does well. Many other partners are struggling to survive, especially in the less developed countries and for them probably it's not really good that more focus is put on bigger customers than on smaller and amateurish ones. I remember, at my first and second jobs how we struggled to sell just about anything to just about anyone, because we had no sales for 6-9 months in a row. I solved this problem by changing where I live and being more careful about choosing my employer, for but not everybody can do so, I suppose.
If things will develop in this direction, NAV will sooner or later have a competitor "from below", a smaller, cheaper ERP system for the smaller clients with a simple and free database, low technical requirements, little configuration required for basic usage, focus mostly on development and not on installation and configuration etc. i.e. something like NAV 2.6-3.7 was
Particularly with this part as I am thinking of one client in particular who fits your description and won't go above NAV5 for the reasons you suggest...I guess I am lucky that he loves NAV and would prefer an 'old version' to a different package....
I realise that a lot of the problems that I face with the RTC can be solved by deploying the Classic client on some desktops / some clients and that the RTC has benefits for many.
However, my biggest concern is the use of the name 'Classic'....doesn't exactly create confidence that the 2 interfaces will remain in future releases and without it then those smaller sales WILL be lost and not easily replaced for the smaller reseller...
Soooo...does anyone know what MS have said on this for the next release(s)?
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
You can still install NAV very easy on whatever hardware you want with next, next finish.
Any cheap small business server from your local staples office center will do.
SQL Express is free and will always run. You can still use CRONUS settings and be live and running in 1 one day.
Just because it looks nicer it is not more difficult.
SQL Express is free and support up to 2 GB. So it really does not add cost to the end user buying the solution.
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
The classic client will not be available starting with the next version...according to the last MS announcement.
From their stand point this makes perfect sense. You have four ERP systems with the same interface...that means (hopefully) better technical support from their end across all product lines. MS focuses on the Dynamics product line as a whole, not just NAV.
So what will the development environment be? :?
Do you want to make a small bet on that?
Statement of Direction
Date: May 2009
Rather not... 8)
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
A joke maybe?
I believe you were at the room with me at Directions 2009 where the MSFT presenter says that C/SIDE will not be going away.
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
I am sure that must be a joke, a very very bad one at that!
NAV is all about quality add-ons & development....Take out the development environment and leave it to the half-trained, half-brained consultant to 'configure' - would be SUCH a smart move
RIS Plus, LLC
I think it is quite disturbing that you take this so serious, especialy in this thread...
Have a little bit more confidence in our friends at Microsoft, they are doing an exelent job with our product.
Someone should close this thread and maybe delete some posts.
haha, not a chance.
I can just see it now. Some competitor of NAV will release news like:
"Confirmed by Mark Brummel, a MVP for Navision, that NAV will be a fixed application."
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
Don't tell anyone... [-X
I think the Pages will be a good direction in the long run. A few things need to be ironed out, generally accessibility, but the direction is good.
(Accessibility: support small screens and poor eyesights. Poor eyesight in IT is the same thing a wheelchairs in the construction industry: a disability you just cannot ignore. Therefore:
1) Make font size increasable and descreasable like in IE8
2) User-configurable colours or using Windows Theme. The point is not
the eye-candy but the ability to have high-contrast colours for people with a poor eyesight - or those dust-covered, half-dead 14'' CRTs in my proverbial - but very real - warehouse example )
3) Do something with that tiny little yellow lightning. Make it bigger, add some text below (screenreaders!) and for god's sake, don't make it invisible when your pointer is howering on the main page! Yes the animation when it appears when you move your pointer down looks very hip and cool and all but just who thought it's a good idea from a usability and accessibility point of view? Now with a metadata-driven client these things are easy for MS to make configurable by end-users. One boolean variable If anyone from MS reads it, please make it so - or even better, simply perform a thorough accessibility test!
Hint: whatever helps people with poor eyesight is exactly what helps people with poor computer skills! (Hint2: if you know a person you are trying to teach to use the Web but it's not going well, increase the font size in the browser!))
So there are this details to iron out but I think the direction with Pages is OK. I can see a day when it will be great and that day is probably not very far - like, this year.
I see much bigger problems with Reports. With Pages you can sense the good direction even if you have issues with it as of now, but with Reports I don't even see it's getting anywhere. The problem is on both ends of the ability scale.
1) You can no longer leave report formatting or f.e. adding a new table field to key users, internal IT or your own junior support consultants. Everything requires a developer, not because it's hard, but because it's that everybody but developers tends to refuse even to install Visual Studio, let alone start it or learn it's report designer. Actually these formatting or adding a new column issues are not particularly harder than in Classic but for many people it's a matter of principle: I won't try to change the oil in my car even if it turned out to be easy because I'm not a car mechanic, and a lot of people are unwilling to start Visual Studio because they are not developers. Expert tools are for experts.
RDL is just XML. Could MS perhaps publish a simple, standalone editor for it?
2) Some things are impossible: for example, TransHeaders and TransFooters. I've heard it from someone who heard it from MS to don't even try, it won't work. And there is this thing about different business cultures: I worked 2,5 years in the UK and never created one TransHeader, but in German-speaking countries they are about as traditional as beer ("Zwischensumme" and "Übertrag", or something like that. I'm not yet fully fluent.) So there will be complaints, I'm sure.
3) Some other things seem to be very hard. It's probably just because I'm not yet experienced with it, but I miss the flexibility of CurrReport.SHOWOUTPUT. Probably it can be worked around - I think if MS could convert R120, R260 and the EU-reports (like VIES) then nothing is impossible to convert, but it seems hard. It' MUCH harder to convert Reports than to convert Forms.
I can see three ways of improving it. Either, make IncludeInDataSet truly work for reports - forget this silly stuff about the hidden yellow fields and let just make a global variable ThisAndThisLineShowOutPut, set it IncludeInDataset, set the variable in OnAfterGetRecord and access it easily in the Hidden property in VS. (I suspect what MS had done was to save the report as HTML and simply hand it over as a website datasource.) Or, forget about using the sections as DataSources and turn DataItems into DataSources. Sections are for representation, not data, and in the MVC way of thinking turning a View layer into a Controller for a different View is simply a category error. Third, forget it all and simply let us write our own DataSources with Visual Studio and LINQ. Isn't it what LINQ is for?