When giant software companies making billions by simply adding more functionalities to existing software and releasing new version of it the paradigm shift to Cloud Computing change the way we think about software. The term Web Application can’t be considered yet another website with may be lots of form and Ajax actions bluntly. Today application inventor has all entrepreneurship ready to imagine their client server or desktop software to be delivered to the cloud and when that sounds enough promising and glamorous at point without proper design methodologies porting the exact functions may become impossible leaving extended vision alone.
No Matter what company promises you “It will be done” its only insider knows that’s Web Application design is a pretty myriad topic without one stop comprehensive guidelines available for anyone. This leaves companies in vague even after starting actual coding process and at point becomes difficult to keep balancing the design strategy with coding strategy. Design is not something that should keep evolving along with code but many times this does happen and chances are high that greater functionality software lacks on better look which were there in first place when the app was planned.
As a company our experience in web application designs started much as a struggle with web 2.0 transitions started happening in year 2005. There were no fixed standards available for Ajax and not even enough examples available in cloud to refer. Sometimes people could make the design work but backend coding was hard and if the code gets working designing was tampered. After testing enough dirt we made Ajax as part of our design flow rather than coding and from that point onwards till today it’s just assured us stable designs and freedom for the code.
Below are some considerations what we put when designing Web Applications
The job is relatively easy when a desktop or client server application exist and getting ported from screen to screen. It is still necessary to have flow charts and UML, however it goes straight when all functions are clear on first hand. Over the years we have developed an understanding of what limit comes when certain functions goes to web interface at the same time we have also visualized possibilities of scalability and beauty of web that can be used. When it comes on to Applications from scratch then it involves tremendous quantity of continual research and place blocks together with pen and paper. We then work with design flowcharts and come up with early mockups to get a basic understanding of where it is heading. For Applications those are done from scratch, we also try to understand client’s vision as well enterprise values before starting an execution. This makes us going either on the next step or allows a freedom for client to press the stop buttons faster.
User profile matrix
We all are aware that everyone design the layout in Graphic programmed first and then slice the HTML out of it to send for further coding. The real trouble over here is avoiding reuse of HTML template since it does not guarantee a consistency. We execute every single screen in UI development software itself in order to make sure that we have completely understood the client requirement as well passing on 'what is expected’ to the programmer alongwith developing a user profile matrix which helps understanding roles of each user types in the systems.
Using Requirement specifications are always wrong can be a bold statement here however alone Requirement specifications never get the job fully successful. In early development cycle we constantly keep prototyping, testing, analyzing, and refining the app for better use. Our adoption of Agile Development Process helps a lot in the process. It also assures glitches pointed out far before they travel further and makes bigger critical issues later
User Centric Approach
All applications and application designs developed are passed to four different types of users at client’s end as well our end in order to understand how they react to the app and how easily they can use it. This helps us showing to the customers concise areas for specific actions than showing one large page of every possible entry that needs to be done and assures that customer passes a feedback on specific areas rather getting exposed to complete under construction blueprints of the software.
Time based training considerations
Whenever we are developing for specialized companies with their own strategies and understandings of the data developed through several years we know that they internally know what the business is all about and making specific requirements for their users using their vocabulary makes the software more useful and more adoptable than standard way. When the client is ready to anticipate larger time for training considering nature of the business than application itself alone, leaves us delivering stable models than flashy models of the design. At the same time if any application is targeted at novice users from any part of the world follows faster adoptable possibility designs.
Using these techniques with eye to the details and effective documentations can result in a highly effective application design. We make sure we have members with a commitment as well strong discipline of design iterations.