Developing web sites that imitate desktop apps. How to fight that paradigm? [closed]

Supposse there’s a company where web sites/apps are designed to resemble desktop apps.

They struggle to add:

Splash screens
Drop-down menus
Tab-pages
Pages that don’t grow downward with content, context is inside scrollable area so page is of a fixed size, as if resembling the one-screen limitation of desktop apps.
Modal windows, pop-ups, etc.
Tree views
Absolutely no access to content unless you login-first, even with non-sensitive content. After splash screen desapears, you are presented with a login screen.
No links – just simulated buttons.
Fixed page-size.
Cannot open a links in another tab
Print button that prints directly ( not showing printable page so the user can’t print via the browser’s print command )
Progress bars for loading content even when the browser indicates it with its own animation
Fonts and color amulate a desktop app made with Visual Basic, PowerBuilder etc.

Every app seems almost as if were made in Visual Basic.

They reject this elements:

Breadcrumbs
Good old underlined links
Generated/dynamic navigation, usage-based suggestions
Ability to open links in multiple tabs
Pagination
Printable pages
Ability to produce a URL you can save or share that links to an item, like when you send someone the link to an especific StackExchange question. The only URL is the main one.
Back button

To achieve this, tons of javascript code is needed. Lots and lots of Javascript and Ajax code for things not related with the business but with the necessity to hide/show that button, refresh this listbox, grey-out that label, etc.

The coplexity generated by forcing one paradigm into another means most lines of code are dedicated to maintain the illusion of a desktop app.

What is the best way to change this mindset, and make them embrace the web, and start producing modern, web apps instead of desktop imitations ?

EDIT:

These sites are intranet sites. Users hate these apps. They constantly whine about them, but they have to use them to do their daily work. These sites are in-house solutions, the end-users have no choice but to use them. They are a “captive audience”. Also, substitution will not happen because of high costs. But at least if that mindset is changed, new developments would be more web-like.

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:

Point to big companies’ (Google, Microsoft, etc) web applications
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
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.
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.

Filed under: softwareengineering - @ 23:45

Thẻ: design, gui-design, management, paradigms, websites

Thiết kế website giá rẻ

Danh mục

Developing web sites that imitate desktop apps. How to fight that paradigm? [closed]