- Form Validation (prior to a request)
- Inline Calculation (prior to a request)
- Hijax / Ajax
- Eager Loading
- Interactive design elements
- For business logic
- Instead of middle tier logic
- For DB / Service calls to back-end
- To mimic native behavior
- To Complex DOM manipulation
If you pretend to be a native application, you are setting up the users expectations. Those expectations will not be met from a request response paradigm.
- that event maybe ignored completely
- that event maybe ignored partly because multiple similar events (i.e. multiple clicks) get "dropped"
- or some other random stuff depending on the specific browser
The questions to ask yourself are:
- Will the site break on the latest new mobile device?
- How will I know if the site works on all key devices?
Is there a reason to add extra complexity? It seems like too many sites have "cool" features that may look sexy the first time you see it but don't actually improve the user experience. These features are very expensive to build, support and maintain. I would recommend "if in doubt leave it out" and if you can't do without it try using A/B or Multivariate testing to show whether new features actually improve profit. Does the business realise by adding these cool features the site will take longer to build, cost more to support and will be more likely to have bugs? In addition in most cases these extra features reduce performance as they add extra page weight.
In summary putting all the functionality into the Web Server or other middle tier components ensures you control of the execution environment. This means complexity reduction, increase of reliability and reduction of testing and maintenance costs. The only hurdle to overcome is to convince the designers to produce a design that is homogeneous across all channels and doesn't behave like a native application.
It is of course possible to build a web application that behaves like a native application. However, the question is not whether it is possible, but whether it is the sensible profitable thing to do.
- Encourages all developers to push complexity from the browser where it is expensive into the middle tier where it is significantly cheaper for development, testing, support, and reliability.
- Ensures your site will work across the widest range of devices as you are reducing the capability the device needs for your site to work.
- Reduces the cost of testing, as it is simpler to test middle tier code using automated tests (i.e. unit tests). Browser code can often only be tested effectively in the context of a web page requiring selenium or some other more complex testing approach.
- Reduces the number of bugs, it is simpler to find and fix bugs in a type safe language such as Java or C# where the compiler does a lot more checking of the code.
- Reduces the required skill level of developers. Developing in the middle tier is an easier task and requires a lower level of skill therefore it is possible to employ a less senior (cheaper) mix of developers.
Build Mobile First. This will encourage you to reduce complexity. Remember 80% of your customers use the core 20% of your features. These are the features on a mobile site, perhaps these should be the features on all channels?
Ask why complexity is required in the browser? Does it warrant the product release being delayed, costing more to build, test and support? Is the correct trade-off being truly considered?
Use A/B or Multivariate testing to demonstrate whether "cool" features have a long term impact on profitability.
Ensure the Product Owners, User Experience, Designers and Developers understand that complexity increases costs, causes delay, reduces flexibility, and reduces reliability. Decisions need to be questioned using MoSCoW or some similar techniques.
A general principle to follow for multichannel sites is don't try to compete with native applications and when in doubt, leave it out.
“No matter how beautiful, no matter how cool your interface, it would be better if there were less of it.”