The mobile web: design vs. reality
At Lundegaard we have successfully completed an extensive project for CETELEM ČR, which in itself included various interesting technical solutions but also a few development blind alleys. Let’s take a look at what should be prevented, what’s better to discover right at the start and what to do to achieve the best result.
When one says “the mobile web”, most people imagine just an optimized desktop website, which can somehow be used on mobile devices. Partly, this is true, as it was majorly correct several years ago. However, the situation is developing and modern mobile websites are essentially done as separate projects, which can (but don’t need to) use the same information sources as a ”normal” website.
The practical annual development of solutions has been reflected in many aspects in the concept itself, used technologies or the integration to the current website. Was the original proposal alright or has the final one vastly changed? Were the implemented technologies the right ones or should they be changes in regard to the development of the project? There’s not a clear answer for this and not every dead-end is downright bad either.
Specification, proposal, analysis and a mutual approval of the project’s scope
In the beginning, of course, there is the classic specification from the client that describes the reasons, benefits and the client’s expectations from the mobile version of the website. In this case, the brief was very clear, constructive and it had describred some of the features for the mobile solution that the client either wanted to include or not. Our job was to build the concept that would describe all the features in a nutshell that define the creation of the mobile web.
Looking back, it’s good to point out which decisions were correct and which where wrong and mainly defining why. The first important decision was building the mobile website as a completely separate web application independent from the “big” website but it also had to use the same interface defined by the client’s internal system the same way the common website does.
These facts meant three things for us:
- Use a suitable CMS as a robust base and be sure it will be usable in the near future as well (CMS LARS Vivo in this case), regardless of what CMS the “big” (desktop) website is running on.
- Have freedom in the approach, design and functionality of the application, and don’t tie it to the standards of the “normal” website.
- Be knowledgeable of the client’s backend systems that are necessary for operating the substantial part of the solution.
The second important decision was defining the supported devices and therefore setting which technologies should be used. This happened to be the most complicated and most important point when it came to decision-making, creation itself and project managing. The charts showing the stratification of smartphones in the Czech mobile market clearly allowed us choosing technologies for the “smarter” devices and that the “dumber” ones would have limited functionality or appearance of the application but nonetheless, we would not be optimizing for them.
Therefore, this decision meant:
Clear proposal of technologies and supported devices.
Elimination of the need of a „light“ version („dumb“ phones won’t be supported).
Implementation of the jQuery Mobile framework for rendering the UI controls.
Using a framework would simplify the process of updating supported devices.
The other decisions are not as important and their changes don’t affect the final solution. Thus I will mainly focus on the two premises as described above and how they influced the development, integration and the project as a whole.
Make sure your specified supported devices are really working
At first it seemed as only a few minor adjustments were needed, so we decided to stay on the used framework. But then the number of unsupported devices that needed adjustments, started to incidentally increasing.
Double-check what devices the company’s management is using!
Yes, it’s true, more or less, the management usually uses something we call “the helicopter view” – they are aware of the project but the details are not important. However, during the presentation to the management of the company, we have stumbled on the fact the devices they are using (for various reasons) had major challenges when viewing this project.
Yes, these devices weren’t on the compatibility list, so from a project standpoint it’s fine, but of course, an indisputable requirement arose for implementing support for these devices.
Standard options vs. requirements
We ran into a sticky situation when the client requested adding several visual features not supported by the framework. The main and huge advantage of using a framework is its simplicity across a variety of supported devices, of course. A set of skins and templates are already created and their colour is customizable. But having a rounded or square corner, that depends on the target device.
If you start thinking about implementing rounded corners everywhere in your project, or you want to place icons on the right side instead of the default left side in your chosen framework or just adding text to a button that didn’t allow it previously … I have only one advice for you – start designing systems outside a framework!
Unfortunately, the demand for these detailed changes arose at the final stages of the project and therefore it was not quite possible to leave the system and throw away several months of work. However, after the experience of editing pixels in detail and adjusting their slightest differences on different devices, I can say it is much more efficient to go back to the drawing board and do everything completely from scratch again, in-house.
Obviously you’ll lose the option of easily integrating new things and getting updates within the framework, and theoretically you won’t have a very broad base of testers – but it proved useless for us, because most of the supported devices didn’t work properly. But above all, you’ll avoid many, many technological constraints that the framework provides.
Management and cost
Since the beginning of the project, basically from the early stages, it was clear that there will be challenges ahead and therefore the project will need managing with clear documentation, multiple acceptances and mutual agreements. Parts of the project was, if the time allowed us, managed in an agile manner, so we could meet the client’s demands. Still, strict management is not only good for the supplier but also for the client, who has a comprehensive overview of what’s happening and is informed whether the specific requirement will mean a significant cost.
Straying from the initial plans and defining newly supported devices not only stretched the project’s time-frame but also greatly increased costs of the implementation itself.
The fundamental change in philosophy in the final phase of this project gave it a different dimension mainly when it comes to resource management and overall perfomance of the tasks that laid ahead.
Creating the Cetelem Mobile Website wasn’t easy, both from a technical and managing standpoint, but in the end, the end result is very positive. The integration to the current web-based solution is spontaneous thanks to its complete seperation of both platforms that the parts are running on. Furthermore, they are both very closely linked via an internal system of the client so that work together better.
The multichannel solution gets a whole new dimension, as you start doing what you need on your mobile phone and finish it on your computer, or vice verca. And all this without having to run both systems run on the same common platform!
Over the period of this project we have gained a lot of valuable lessons and know-how that help us design similar systems more effectively and mainly it’s much easier to fix the used technologies at the early stages.