Posts Tagged ‘javascript’

The Rich are Getting Richer

March 17, 2010

The last twelve months have been tough, with many businesses and individuals struggling against the change in economic conditions. But while times have been tough, many of the most popular news items have also helped highlight inequalities.

From the expenses claims of errant MPs through to large bonuses for failed bankers, individuals in all areas of the UK have been surprised how – at times of hardship – the rich seem to be getting richer. And the web is no different.

At the same time as a change in economic conditions, businesses face a change in marketing and buying. More and more individuals are choosing to interact with companies through the web – and some firms are struggling to respond effectively.

At this time of new interactivity it pays to focus on the customer experience and with that to differentiate yourselves from the competition by the quality of the customer experience. Leading firms are responding by making sites increasingly interactive, rather than the passive click and refresh approach the web was born with.

Improvements in web technology and broadband access have overcome the limitations of the early days of the web where customer experience design focused heavily on performance because of the technology constraints. With these issues lessening the new age of interaction presents a plethora of means for collaboration and slow-moving companies now risk being left behind.

High-intensity web sites provide a much more responsive feel akin to desktop applications and also provide a range of communication tools. Click on to a an innovator’s site and your likely to have a range of ostentatious options, including speech response, chat/video messaging and animated forms.

However web trends come and go increasingly quickly; today’s Twitter is tomorrow’s Friends Reunited. I have seen the issue of page scrolling from being cool to being a huge design sin and back to cool.

Expect also a greater range of form controls being deployed as the basic HTML controls only provide lists, edit fields, text fields and buttons. Companies are now buying or creating their own widget libraries to enrich their palette of form controls, note the recent advertisements from confused espousing the ease of use of slider bars.

With richer experiences expect to see animated page transitions, windows/pages no longer to be square, more visualised data than text, multi-media experiences using sound and video.

So the rich are getting richer, the only question is when will you join them  !


Digg!

Client Side Session Management…

July 18, 2008

Ok this is an old hobby horse I’ve reeled out many times, and now that I’ve got round to starting a blog what better place to find a permanent home for this old equidae.

The traditional way of managing sessions is on the server with the application container managing session keys/data. As a front end developer your job is simply to populate the session data as it is capatured on screen, the application container does the rest for you. The application container should offer different mechanisms for replicating session data across servers, thus providing session failover. It should also optimise the storage of the data itself, and manage the session keys with it’s own policies for clearing out dead sessions.

The problem with this model is that it is simply not that easy. Some of the issues that need further consideration are: Memory optimisation, Long vs Short Running sessions, Server Redundancy:

When storing data in sessions, the data element is normally given a name, generally this is something meaningful that a developer can use to make code more readable. However these name themselve take up memory. Whilst this may not seem a huge issue with the amount of memory in servers these days, we’ll see later in the post why optimising memory for sessions is necessary. So one improvment you can make is to implement hashing to reduce lengths of names used in code. Another technique would be to use compression for the actual session data especially for large free text fields.

Generally there are two types of sessions long running or short sessions. Typically internal applications such as call centres will have users that log-in in the morning use an application all day, and log-off at the end of the day. Such applications if not designed efficiently often do not release session data during the session, this can have the issue of builiding up huge memory requirements per user of the application. Prior to memory depletion, performance degradation will be the first issue as memory is swapped in/out of disk, followed by out of memory server crashes. Hence developers need to consider what memory should be held and when to release this memory. Short running sessions with mass users e.g. shopping sites, tend to have less per user storage requirements but many more users, creating a large memory requirement overall. In this scenario identifying dead sessions is paramount to reduce memory redundancy. Other optimisations include identifying session data that is used not per user but globally across all sessions, and caching one instance of that data rather than load it per user.

So it is for reasons like the above why client side session handling make so much sense, if only it was supported as standard by the browser rather than having to use hidden fields. Quite simply client side session management is a means of keeping data in the browser rather than on the server, therefore reducing the memory requirements and extra processing that an application container has. It would not only reduce the cost of the server you’d need it would also improve performance of the client application also, more so than the use of Ajax.

I can’t think of any downsides to this approach whilst the upsides are huge. What do you think?


Digg!