The Figure below clearly depicts the exact evolution of web application all the way from its humble beginning in early 90’s to the current state.
It’s very hard to clearly separate Web 1.0 from web 2.0 as there wasn’t anything different which got introduced in Web 2.0. That’s the reason the figure above clearly doesn’t put in a timeline as these are not very clearly defined. Having said that, it evident from the figure that, over the last few decades there has been substantial change in how we see web sites/ applications. When the web initially started, these were not called as applications; rather these were called as sites, with static content and hyperlinks which allows users to navigate from one content page to another. After that came the existence of CGI and Servlets which allowed these static sites to become dynamic and more personalized. These sites slowly started calling themselves as applications as they start to do some basic stuff which a client server application could do for a user. The scene of web applications quickly changed with the introduction of MVC frameworks (In the world of Java Struts was one of the initial MVC frameworks) and the templating engines. These changed the way we looked at web applications and there was a huge rise in people adopting it to make web applications for businesses. With the introduction of Web 2.0 standards, another important addition to the web came into existence in the form of AJAX, which helped web applications to render parts of its page rather than generating the whole page at once. This made web more rich, faster and importantly brought about good user experience. With web 2.0 came into existence new standards (HTML5, CSS3 etc.) and these completely changed this space and a new paradigm shift began to be thought through in the form on client side MVC frameworks.
Disclaimer: The content in this blog is plagiarized from various sites and blogs and is considered as a place where all their views are consolidated and put into a view which can be used as a guideline for any web application development. All the articles from which this blog is based is given below in the “Reference” section. Thanks for all the great authors and their work. Truly Appreciate!
This document aims at providing a basic guideline using which UI/UX team can develop the web application story board. Mobile optimized web application is gaining traction and it’s time for any web application being developed to consider mobile devices. On a high level mobile optimized sites can be built using the below:
Responsive Web Design (RWD) – The document does give more insights and details on this design as this most talked design consideration in regards to web application.
Having different set of HTML and CSS catering to desktop and mobile device served by detecting the user agent and a single URL. Not considered to be a real way forward because of alternates (RWD).
Two set of URL for desktop and mobile and is decided agent sniffing the user agent. Again, not considered as a choice because of alternates available and cons attached to it is high as opposed to pros.
Some of the design principle which needs to be kept in mind is:
Responsive Web Design
Progressive enhancement and gracefully degradation
Responsive Web Design
Figure 1 Responsive Web Design
Ethan Marcotte coined the term responsive web design (RWD) in the year 2010. Responsive web design is a setup where the server always sends the same HTML code to all devices and CSS is used to alter the rendering of the page on the device using media queries. In essence responsive web applications respond to their environment. It’s considered as a cost effective way to mobile application. RWD is achieved using the following:
Fluid/flexible grid-based layout
Fluid images and media
Media queries and media query listeners
Having said that we can indeed have a mixed approach where we have a fixed width for large and medium screen widths and fluid widths for small ones. Whether small, medium or large, one site for every screen out there is the ultimate aim which RWD brings onto the table.
Day by day number of devices, platforms and browsers are increasing and your application should be able to support as much as possible without breaking and without compromising user experience.
A single URL for a piece of content makes it easier for your users to interact with, share, and link to your content
No redirection is needed for users to get to the device-optimized view, which reduces loading time. Also, user agent-based redirection is error-prone and can degrade your site’s user experience
When to use?
Time & Money
Website Vs. Web App
If you go for framework, it will definitely save time. Otherwise, we can go in-house, to have more control but we might be stuck where we are if there is no roadmap. There are good amount of frameworks, well tested and established which can be used:
The Goldilocks Approach (http://goldilocksapproach.com/)
At an onset, Twitter Bootstrap is the most promising one and once we do a full on paper evaluation to arrive at a choice.
Historically, most web designers and their clients have approached the desktop side of any project first, while leaving the mobile part as a secondary goal that gets accomplished later. There’s a growing trend in the industry though to flip this workflow on its head and actually begin with mobile considerations and then work up to a larger desktop version. Mobile-First Responsive Web Design is a combination of philosophies/strategies, and ultimately boils down to a broader application of good old web best practices. As the digital landscape gets increasingly complex, we need to design experiences that work across the entire spectrum of digital devices.Mobile First is a philosophy created by Luke Wroblewski and as detailed above highlights the need to prioritize the mobile context when creating user experiences.
Mobile isn’t a trend, nor is it even the future, it’s the present.
o Almost 25% of the Web’s traffic now comes from mobile. If you didn’t build a responsive site, you’re already losing a quarter of your users.
o Mobile device sales are increasing across the board with over 85 percent of new handsets able to access the mobile Web
o Mobile device sales are increasing across the board with over 85 percent of new handsets able to access the mobile Web
There are good amount of tools, technologies and framework available which will let you do this design principle easily.
Announcement from Eric Schmidt in 2010 that Google was going to be taking this approach from now on. No problem going behind great leaders in this space.
When to use?
All the points as discussed in RWD holds good. It does put some constraints and pressure on the developer but its worth in long run and above all good for business.
Progressive Enhancement and Graceful Degradation
Mobile-first responsive web design comes down to using Progressive Enhancement and Graceful Degradation as a foundation for web strategy and design. Designing with progressive enhancement involves smartly adding layers of enhancements to a strong foundation in order to deliver an accessible and optimized experience to all. Starting with mobile and designing with progressive enhancement covers all bases (even if just at a rudimentary level).
Figure 2 Progressive Enhancement and Graceful Degradation
Note: Don’t misunderstand visualizing the above figure as almost equal to the RWD figure. Not only will the form factor changes when being used across multiple devices, the capabilities of browsers rendering these pages also have different capabilities.
Figure 3 How an application should be conceived and designed to achieve this design principle
Figure 4 How the code should be structured to achieve this design principle
Figure 4 above explains Figure 3 in technical aspect clearly. You need to have a base HTML along with base CSS and JS which renders just fine in any browser (old ones). You need to have next set of nice CSS and JS which will adds more styles and behavior to the base one which works just fine in medium range browsers (IE 6, IE 8 etc.). You need to have awesome CSS and JS adding on top of base and nice CSS and JS, which will run just fine on all modern browsers (Chrome, Firefox etc.).
If this design principle is not given due respect, developer may limit the websites functionality considering it work fine in older browsers
Sites break when rendered with older browsers
Use HTML 5 and CSS 3 and make sure that the code is W3C compliant
Consider above design principles in all aspects (guideline as to when each should be considered is detailed in the following section)
Use detection libraries like Modernizr (http://modernizr.com/) to eliminate or rather adapt your web application to various HTML5 and CSS 3 capabilities each browser supports.
Any web application being developed can be categorized broadly into different categories. One such category is:
Internet based (staff as well as external customer accessing web applications)
Intranet based (exclusive for staff)
Another way of categorizing a web application broadly is as below:
Web application having a definite mobile strategy
o Maintaining a mobile only site and based on the user agent detection call appropriate URL’s
o Having a native application specifically developed to cater to the mobile devices
Web application not having a definite mobile strategy
o Most of the intranet staff application fall into this category (this is something which has been done in the past but with the growing tendency of staff asking for application to be accessed using a mobile device is growing)
For internet based web application having a definite mobile strategy, making the web application align with these design principles should be looked upon on a case to case matter as there is a cost involved in making a web application align with these design principles. Since there is a mobile strategy already existing for this web application, users does have an alternate way of accessing the application wither using a dedicated mobile URL or using a native app. Having said that, both mobile web URL and native app does have some dependency on the device being used and ideally considering the cost, going with our design principles and considerations as detailed above is encouraged. For internet based web application not having a definite mobile strategy, the application should be built using all the design principles and considerations as detailed above. The reason being, the application can be used by users in different parts of the world using different devices and browsers and the application should be ready to support this diversity. For intranet based web application having a definite mobile strategy, to not overburden the budget the design principles can be compromised but considerations should be taken into account and implemented. Ideally, if the application is responsive in nature even the mobile strategy of either having a dedicated URL for mobile or a native app can be reconsidered and can be taken out of service and replaced with the responsive site. For intranet based web application not having a definite mobile strategy, according to the usage patterns (analytics gathered from existing application or forecast and prediction on usage of mobile devices) the decision on whether to go with design principles has to be made. But, the considerations have to be taken into consideration and implemented. Note: Optimizing for every web-enabled device on earth is impossible, so eventually you need to make the strategic decision of what target devices and browsers for which the web application needs to be optimized. This decision can be based on existing applications analytics per market research on target web applications user base.
Users care for content
Users use only one browser
Give incentives for users to upgrade to a modern browser
Support best possible experience (based on device and browser capabilities), not the same experience for all users
Do your presentation/styling using only CSS (CSS 3) rather than using tools or manual coding
Don’t try to make older browsers to do things they are never meant to do. If you do, you will have long development time, too many bugs and it will perform badly (slow pages).
Set of Html’s and CSS (the URL remaining the same) catering to whether the user agent is desktop or a mobile device seems too much maintenance havoc and should be avoided and replaced with RWD.
Recently i have written a blog on how to implement PRG pattern in your Spring MVC web application in here. In this blog i would explain implementing this pattern in your JSF based web applications. I think this can be used for any JSF implementations like RichFaces, MyFaces etc.
Having said that, for me writing this blog post is very easy as i am not going to write it myself. Rather i would direct you to well written blog on the same topic by Ed Burns in the below URL:-
Do you have back button issues? Duplicate form submissions when you click back button? I think you have landed in right blog. With respect to Spring MVC, the blog even tries to give the complete solution by which to handle it.
One of the easiest way by which you can handle these issues is by implementing Post-Redirect-Get (PRG) pattern.
What is Post-Redirect-Get Pattern?
Post/Redirect/Get (PRG) is a web development design pattern that prevents duplicate form submission. When a web form is submitted to a server through an HTTP POST request, a web user that attempts to refresh the server response in certain user agents can cause the contents of the original HTTP POST request to be resubmitted, possibly causing undesired results, such as a duplicate web purchase.
To avoid this problem, PRG pattern is used, instead of returning a web page directly, the POST operation returns a redirection command. The HTTP 1.1 specification introduced the HTTP 303 response code to ensure that in this situation, the web user’s browser can safely refresh the server response without causing the initial HTTP POST request to be resubmitted.
I don’t want to re-invent the wheel, so i would just let the reader go through the Wikipedia which has explained it beautifully. Please follow the following URL:
Beautiful well constructed figures in Wikipedia will make you understand this pattern in minutes.
I hope you would now have a clear picture of PRG pattern after going through the above URL and are ready to see this implemented in your Spring MVC application as detailed below in this blog post.
I really don’t know whether this is the best approach by which Post-Redirect-Get pattern can be achieved in Spring MVC. Nevertheless i am sharing an approach below by which PRG pattern can be achieved. If this is not at all right approach, or there is another good way by which to do it, please let me know through your comments to this blog post and i promise to correct it accordingly.
In Spring MVC PRG is implemented by having two request-mappings for each page one for GET and the other for POST. The page should always be rendered using GET method and the form should always use POST method for submitting data to controller. To achieve PRG after submitting the form in the POST method of the request should send the response with redirect to the page, by doing this the page will be rendered using GET request. The following a sample code.
As I speak/write the blog is kept on updating with the reasons on the choice of various technologies/framework. Please look into the blog for more updates. Please look into the first part of this blog in here.
Get the requirements from the business
Converting business requirement into meaning user story board
Once getting business confirmation, pass on the HTML’s to the Java developers for making it dynamic and functional in all nature.
Once the developer gets these HTML’s as designed and agreed by business, if you use any of the component based web frameworks, looking at the HTML provided, it has to be designed from scratch. The developed final HTML which is required will never be achieved by the developer and this can be a big issue to the business. By using such a basic web application framework like Spring MVC will avoid this and the developer will be bale to use the HTML as given by the graphic designed and convert into a dynamic web application. The business will get the same look and feel which the graphic designer as shown and overall the project can be completed in a much shorter span of time.
Thymeleaf / Apache Tiles (Templating framework instead of using JSP directly) – One of the greatest features that i see of Apache Tapestry (a web application framework, initial release, Tapestry 4 and older, before the framework rewrite) is the full use of the graphic designer supplied HTML’s by the developer’s as is and making necessary changes so as to make it dynamic in nature. Thymeleaf brings that advantage onto any web application framework and acts as the templating framework. But there is an issue using Thymeleaf along with the security compliance framework namely HDIV, down the lane I will explain this and how good is it for your web application to use HDIV to cover OWASP security requirements with ease by mere configuration. If you want to use HDIV, the next best templating framework that you can use with your web application framework is Apache Tiles. For more details on Thymeleaf please go through http://www.thymeleaf.org. For more details on Apache Tiles please go through http://tiles.apache.org.
SiteMesh (Decorator – Filter for layout creation/maintenance) – Using a templating framework and layout framework might not be well accepted, but i feel if the application is developed keeping in mind to be made into product and customization in mind, using this layout framework along with a templating framework will be good overall. For more details, please visit http://www.sitemesh.org.
Dandelion datatables – Dandelion is a component of the open source web application framework Dandelion. It uses DataTables JQuery plugin to create full-featured HTML based tables. There are variety of ways by which to use the tables in your web application, easy to use, integrate and customize. Any web application requires a datatable for displaying data and nowadays the expectation out of a datatable has grown out of proportions. Using Dandelion will help you realize these to a greater extend with not much hassle. That’s the reason for me to choose this and being a JQuery plugin, makes it even an easier choice. To know more details on this, visit http://dandelion.github.io/datatables.
Bootstrap (CSS) or Blueprint (CSS) – If you don’t have a graphic designer and you are told to do the graphics and design of the web application, i would suggest using either bootstrap or blueprint. These give a head start, suing which the skeleton of the web application can be built and it id designed by experts, so why use their expertise. For more details on bootstrap, please visit http://getbootstrap.com. For more details on blueprint, please visit http://www.blueprintcss.org. As the project name suggests, bootstrap gives you the head start and blueprint give you the blueprint on which to bild you web application. It inherently takes care of many things for you, on such example is browser compatibility and graceful degradation.
D3 JS or Highcharts JS – Both are fabulous charting framework. Both are really good in features and if you application is chart/report oriented, not using any one of them is a crime. D3 can be used for commercial projects for free but Highcharts can only be used freely for non-commercial projects. Since these are JS based libraries, usage is easy and wouldn’t be that troublesome. Highcharts being a commercial products boasts good support and browser compatibility and as its a de-facto requirement, supports graceful degradation according to the browser in which you web application is rendering.
Modernizr (Browser detection and grace degradation in case you are using HTML5 and CSS3) – If your application is based on HTML5 and CSS3 standards, using this JS would be handy so that the web application can degrade gracefully according to the browser in which the application is loading. For more details, visit http://modernizr.com.
HDIV (HTTP Data Integrity Validator) – Good things come later, isn’t? To me one of the best Java Web application security framework. Integrates well with major web application framework and templating frameworks. Just by using this framework, you automatically get your web application security requirement covered to a good level. The framework takes care of almost all the top 10 security threats as classified by OWASP. It gives you this feature by not tampering with your pages by your developers, rather it sits as a filter (highly configurable), and takes care of all without a single line written in your main application code. At any point, if you feel that this is not doing any justice to your web application, removing it can be done very easily. Its a wonderful handy framework which you can use to get past your company’s security team (VAPT). For more details, please visit http://hdiv.org.
backbone.js – You now really have good amount of JS libraries and maintenence of these can be cumbersome if your web applications keeps growing in size over a period of time. This JS library brings structure to the JS coding as a whole and this can be really helpful in case of big coporate web application. For more details, visit http://backbonejs.org.
Custom tags – Custom tags must be written and used as much as possible bringing in component based development in case you plan to use Spring MVC as your choice of web application framework.
Exhausted. I will be completing my three part series in my following blog post. In couple of days and you will see my final blog. Having said that I will keep updating the earlier blog parts with more and more detail, especially when i get more details from my fellow bloggers/readers.
This is an opinionated blog as I do favor considering Spring Framework in the various tiers of a typical web application. I consider the framework because of its features, ease and above all good enthusiastic community and activity surrounding it as a whole. While doing this evaluation and recommendation, I have put the year, as technology changes are so fast, obsolesce is down the lane and I do want to make sure that it is reviewed in a timely manner so that rather than giving a wrong recommendation, make recommendation to some extent useful and ideal for a typical web application. The whole technology stack can be summarized as below:
Spring MVC (Web Framework)
Thymeleaf / Apache Tiles (View framework instead of using JSP directly)
SiteMesh (Decorator – Filter for layout creation/maintenance)
JQuery-UI (JS) – Theming (More for productization)
Dandelion (For datatables) – JSF datatables are heavy
Bootstrap (CSS) or Blueprint (CSS)
D3.js – for graph representations
Modernizr (Browser detection and grace degradation in case you are using HTML5 and CSS3)
HDIV – to tick all security requirements in your application from a single point. At this point in time, using Spring MVC along with Thymeleaf is not supported by HDIV, but its not far away. So if you want to use HDIV, Spring MVC along with Apache Tiles should be used.
yepnope.js (Script/resource loader)
Custom tags will be written and used as much as possible bringing in component based development
Consider using Spring Data – Different profiles
Things to be considered as a whole:
WebJars for managing JS and CSS libraries as jars
Caching using Ehcache
Multiple DB support (development can be even considered using in-memory database)
Consider using Datatables4J
Reason for each technology/framework selection
As detailed earlier, the reasons that I consider might be fully opinionated/biased, please let me know your suggestions, after careful consideration looking at its advantages/disadvantages, the technology stack will be considered and changed accordingly. For the year 2013, I consider this blog as evolving as possible according to the suggestions that I get from the readers of www.javacodebook.com.
I will have another blog written very soon (2 days’ time) giving the reasons for each choice which I made so that while you do a selection in your project, you do have enough reasons and points to be given to your management.