This sounds like the underlying problem is a failure to adapt. It will be difficult to convince them they should as well. I think your best bet would be a combination of things:

1. Point to big companies’ (Google, Microsoft, etc) web applications
2. Make a good list of points on the difference between desktop apps and web apps and why they shouldn’t try to act the same
3. If all else fails make a small-ish example program. Say, a notepad replacement. Make it “desktop on the web” style, and make it in typical web-app style. Show your bosses why people are more likely to use the web-app style.
4. Finally show them that web-apps are the way they are for a reason. It’s cheaper in multiple ways. Takes less time to develop(pretending HTTP is a stateful protocol is such a time waster), less resources to run, and your customers are more likely to pay for whatever you’re selling.

A few starting points for #2:

• It is physically impossible to know for sure that a customer has left your web app. HTTP is stateless. You can do polling, but this isn’t great.
• Web apps do not require installation. This is one of their greatest selling points. Don’t muck this up by requiring a login for things that don’t require it.
• It is physically impossible to know for sure what size of browser-window the user has. This is why flowing layouts are so good, they dynamically adjust to whatever the window size is automatically. In comparison, the desktop-style approach is usually a fixed layout where you’re stuck with basically a lot of wasted screen space for no good reason.
• With web apps, it’s very possible that someone is using a different OS than Windows to access your website. You should strive to use common fonts and not rely on proprietary fonts unless you have a failback font that looks decent.
• HTTP is stateless. The more you pretend it’s not, the more resources you need to make that “true”. At the highest end, it basically means for each request to your website, you will require sending all of the data from every request to your website since the last visit. Internet is getting faster and servers more powerful, but why buy a 5 mile-per-gallon gas guzzler for $80,000 when a better looking 40 mile-per-gallon car does the same thing for less.
• Users hate being inconvenienced. If your website is stateful and they are about to buy something and accidentally press the browser back button instead of your proprietary back button, that may cause them to start over. Chances are they will take their business elsewhere rather than deal with finding the product again, putting in their info, and actually buying the product
• They should absolutely facilitate the ability of users to share URLs to their content! This is probably the most important point. What’s easier “hey go to this URL and look at this” or “hey go to this URL and then click search, and then type in “super bacon cooker” and then click on the 3rd result, the super bacon cooker XL and take a look at that”…. Can you guess which of these processes a user will never do? Do you want free advertising or not?

Nowhere in your question do you mention the end user. All questions like “should we use design A or design B?” should start with the needs of the users. Are they happy and productive with the current designs, or are they the ones asking for these changes?

A lot of what you mentioned can be used both in successful and unsuccessful apps. Before you go trying to change things, make sure the change makes your user experience better. If the current scheme works for them, why change? If you’re thinking “I think this would improve the experience of my users”, that’s the wrong answer. You need to do just a tiny usability study of just a few real users so you can confidently say “I know this would improve the experience of my users”.

If you want to change the mindset of your team, get them to understand that a) it’s all about the users, and b) the users are not being served by the current designs. If they don’t agree with either one of those points, you’ll have a hard time convincing anyone.

There is a paradigm shift in the web industry. The term SPA(single page application) is getting more and more traction each day, as big projects/startups continues to produce amazing web apps each passing day.

As web is changing constantly, and fast, embracing web is a vague term IMO. The old sync. request-response with full page loads using HTML is being replaced by json over async. requests.

Now, there are two types of ‘things’ on web: web sites and web apps. Each of them has it’s own pros/cons.

programmers.SE is a web site. There is no need for ‘app’ functionality, as the ‘web site’ concept is already useful for a QA network.

On the other hand, Basecamp(online project management software) is a web app. The traditional way of web sites, which includes separate pages for everything, full page loads etc. won’t really fits a project management software. Instead, using the SPA model, you have a software that can be used with a web browser, with the power of a desktop app. Best of both worlds.

The problem is, as always, you should choose which type, web site or web app, fits your product. Take the end user experience to front side when making decisions.

I would point them towards successful web apps by Big Companies that have harnessed the web format instead of sticking to the desktop one. WordPress comes to mind. Google’s business apps as well.

Well of course they want their web apps to behave just like the desktop apps. You want to convince them to drop all of this, even though, they are willing to pay someone to make it work.

Now if they expected you to develop this with the same amount of time and the same amount of performance at the same price, you have an arguement. As long as they are aware of what they get for what they pay for, you should deliver. If I were paying for software and my employees wanted all these extra bells and whistles at my expense, I’d be the one complaining and not the programmers.

You have job security my friend. No one said it would be easy.