What i think apple is cooking, based on IOS7

The new flat design that apple has introduced with the release of IOS7 recently has originated a lot of discussion and criticism. Moving from a skeuomorphic to a flatter design, apple has dramatically changed the UI presentation of its OS.
A lot of plausible reasons and theories have been, and will be published. Varying from Windows Metro copy cat to more philosophical ones.
I think there is actually a more well thought roadmap behind this change.

For a few years now rumors appear about apple manufacturing a smart television. Also apple has some nice television based patents, like this one for a 3D transparent display.

The flat UI design apple is using is based on a monochromatic color scheme and icons and UI elements are line based. This kind of UI is very scalable (size) and typically optimized for 3D and transparent screens. Also the clean flat design without all the skeuomorphic clutter works very well on large screens.

So i think this move will eventually introduce apple’s plan to take on the living room by introducing a beautifully styled glass panel, enriched with a transparent 3D capable OLED layer. This new device will blend easily into its surrounding. It will actually be more than a television on steroids. It will be the controlroom for all our current and future digital activities. It can be controlled by touch, speech and gestures. It will talk to you and give you visual feedback trough a (goggle less) stereoscopic 3D GUI.

The technology is there, the GUI is there and it’s getting time for apple to introduce some new disruptive technology.

Perhaps they can call it the iCentre…

So let’s wait and see!

Here some of the concept impressions i made:

Responsive design at enterprise level: choose the right focus

Responsive design is hot. Everyone talks about it, many people want to implement it, but where to start? Especially in a complex landscape of a large organization, it is often difficult to go from the somewhat abstract term ‘responsive design’ to a solution for a scalable and especially meaningful implementation.

Small versus enterprise-level

One of the biggest struggles when implementing responsive design is to make the translation from the technique or concept to a functional business case. There has much been written about, and there are plenty of technical frameworks, templates and libraries for a quick start. But is this the best approach to implement responsive design in a meaningful way? For small-scale websites and applications this will certainly be the case, but implementing responsive design at enterprise level is less simple.

Optimize the customer experience

Responsive design is a subdomain of adaptive design and adaptive systems. It deals with the optimization of the customer experience based on the user’s context. Responsive design and adaptive systems are in my opinion not the holy grail of web design. It is more a modern design philosophy with which we, in a reactive and agile way, embrace the unpredictability of the future Internet landscape that is coming at us with a dizzying speed.

Context: more than screen size

With responsive design, at first we often think about changing the screen layout based on the screen width or screen context. But the context can be much more complex: a device or browser context may reveal more about the features or capabilities of a device or browser. For example, the geolocation, network speed, and orientation of the device.

If important information about our visitor or customer is available in our backoffice, we can even go a step further by adding this data and enrich the visitors or customer context. With this extra info, the customer experience again can be fine-tuned. The latter has a lot to do with personalization and is similar to segmentation and targeting techniques already widely used within the e-CRM domain.

The hurdles of new techniques

Each new technique or technology has a growth path similar to a steeplechase. Once an initial solution for the problem, and so the first hurdle is taken, we rush for the next hurdle, usually the first hurdle that we encounter. So with responsive design.

Where currently all attention goes, and where everyone has something to say about it, is the content issue. How do we get our CMS to present adaptive content? What is the best content strategy? How do we create content suitable for all platforms? Generally not trivial issues, but these are not goals on their own. They only are means to reach our ultimate goal. The wrong focus on implementing responsive design ensures that we all continue to run circles around the content issue.

The user and the business as stakeholders

But what is it all about? Ultimately, in a web relation there only are two real stakeholders. First, the user and the business or owner of a website as a second one. Both parties have importance in this relationship. The importance of the user can be expressed in a goal and a number of tasks required to achieve that goal. The marketing of a product or service is the importance of the business.

The PEC model

To comprehend the relationship between the stakeholders, I have created following PEC (Proposition Experience Context) diagram. To visualized this relationship, I have added the dimension ‘context’ : an important part of responsive design. The interface from the business to the user will result in a proposition to the customer. Product, tone of voice, visual design and branding is determining the relationship.

The PEC model from the medium perspective

The interface of the user towards business we know in the form of customer experience. The nature and form of the proposition have an effect on the experience of the user. These two interfaces can be brought together via a channel and a medium, in this situation our website. In case of a successful coherence of both interfaces, conversion is possible.

Adaptive system as a medium

When we use an adaptive system like a responisve website as a medium instead of a (static) website, our proposition and the user experience will come to depend on a context. At this point everything comes together: the user, the business and the context of our responsive website. By determine what type of context can add value, and by matching a proper proposition and a user experience, we have put a first step.

In case of a device context, we can determine how we optimize for different devices. If there is a known client context, then we can even adjust our proposition based on a scoring system such as customer value, or by the use of a customer journey methodology. By continuously placing parts of our web environment within this framework, we are able to define in a thorough way how to handle issues.

The PEC model from a context perspective.

Business Perspective

If we start to look this framework from a business perspective, we can use a number of practical tools to determine the correct proposition. Customer value or another scoring system as NPS or CES and Customer Lifecycle Management could be used to set a first base. But especially the new ideas of service design provide the necessary tools to to look for unexpected opportunities in a cross-channel and multi-device environment. Also, by making use of the new context dimension.

The result could be a new service concept or a new site concept. According to the Dutch company DesignThinkers service design is about:

“The alignment and coupling of various stakeholders, services, partners, locations and touch points to an ecosystem where value is created.”

And let this exactly be the situation the PEC model describes.

The PEC model from a concept perspective

User Perspective

If we look at the model from a user perspective, there are a number of UX tools we can use to design an optimal experience. By defining customer journeys and personas, fast insight into how a user could be using our medium can be gathered. And with the usability methodologies, we ensure that the interface, which is a part of the experience, is of sufficient quality and so optimal usable.

But the user also must be triggered to actually make use of our medium in order to purchase a product or service. By applying modern neuromarketing and persuasive design , we can respond more on the psyche of the user. The context component gives us an additional mechanism to adapt the user interaction and presentation of content to suit the specific situation of the user.

The context-sensitive medium

To clarify the above theory I provide some examples. The unique difference between the traditional business-user relationship and the above-PEC model is the presence of a context layer. This is information about the situation of the user. It can be information about the device or browser that he uses, or information about a known customer, after logging in.

Characteristics of the device context can be: is this a tablet, a smartphone, a more ‘normal’ phone, game console or device that is integrated in the car? A practical example of customizing the service proposition to the context is that of a desktop chat functionality as a means of contacting. When someone uses a mobile device, then a chat function may be less useful. In that situation or that context, a ‘call me back button’ could be offered. For visitors using a TV it could be more convenient to offer a video chat, because these users could have no QWERTY keyboard.

Filter based on the context profile

Responsive design is not just a client side thing . It becomes a powerful whole when every system layer involves the contextual awareness and adaptive mechanisms. This means that also on the application layer and CMS-layer an implementation should be given to the adaptive system. Each layer can be used for filtering content based on the contextual profile. When these first steps in constructing a using context profiles are made, a next move could be to investigate whether it is possible to enrich the context profiles with visitor or customer information that is already available in your back-office system.

When creating a responsive concept do not think of or design for pages, but start designing components and assemblies of components. This will ease the translation to technology, and ensures that you remain agile in regard to future channels and devices.

A look into the future

With the advent of social intelligence, big data and the growing mobility of our customers we will increasingly be able to know about the context of our visitors. In addition to the device-related context and the client context that we have in our systems are, more and more will be clear about the actual or realtime context of a visitor.

This context actually changes a lot during the day. In the morning your visitor is an athlete during his daily fitness while he is a businessman when reading the first news after rising. Then he suddenly is a cook who prepares breakfast. Then again a businessman, a friend, a coach and so on. When we know this kind of realtime contextual information it is possible to create personalized and relevant propositions and approach the user within the right context. The domain of contextual marketing is all about giving this an interpretation.

Means to achieve your responsive goal

Despite all the attention for content and technique within the responsive design scene , these are only means to achieve our responsive goal. By focusing on the two main stakeholders, the customer and the business, it can become a lot clearer what the coherence is within the field of responsive design. This makes it easier to make a meaningful implementation to responsive design.

Biggest challenge is on the business side

Break down responsive cases, think in components, use the PEC framework as a reference and remain agile to quickly respond to future developments. With the expansion of the contextual information in the future, we will increasingly be able to create personalized and relevant propositions. The biggest challenge and opportunity of responsive design are perhaps on the business side.

For a Dutch translation see my article on Frankwatching.com

6 threats of the modern FE environment

Web’s frontend has always been a dynamic environment with it’s own specific characteristics. It has gained a lot of professionalism regarding job roles, technologies, processes and as a platform in the last years. But besides this evolutional change, frontend plays a growing role in multi device strategy and application architecture. This evolution, shift and growth can also introduce some possible threats that, if not addressed, can lead to disaster.

Complexity

Our frontend domain is maturing rapidly. We started with a relatively simple web design environment and are entering a full-blown system development platform where we use professional development methodologies that have a high learning curve. Thorough knowledge of structured and Object oriented programming and design patterns like MVC, module, AMD etc is needed. We are continuously shifting away from the open low-level character of our web standards. The user environment is also rapidly expanding. A plethora of devices and browsers must be served. Users are getting more demanding regarding their experience. Browsers are evolving from an agent to a platform where new technologies are growing like a herd of mushrooms.All these new features drive an unstoppable temptation to bloat our frontend environment with all kinds of goodies, resulting in a full fat overloaded client where everything is happening without any goal or fundamental reason.If we don’t continuously reduce complexity, we will end up with a unmanageable environment.

Ignorance

Ignorance of the fact that the frontend environment is an environment with it’s own specific habits, requirements and behavior, and the fact that frontend developers are professionals that are aware of these specific characteristics, can be an important threat. The frontend environment should not be treated as a server side environment, like java or c#. We have to deal with an unstable, unreliable hostile runtime environment, build on a single threaded execution model. we don’t have compilers that save us from all kinds of mistakes. We struggle with runtime isolation, etc.

Agile development methodologies have morphed multi disciplinary teams into omni disciplinary teams where frontend developers have to test and backend developers have to write frontend code. No problem with that. This LEAN approach surely has potential, but it will only work with ignorance-free backend developers. They should be aware of the pitfalls, quirks and best practices of FE development. But we as FE professionals have to make them less ignorant by sharing our FE knowledge.

Complex environments need structure and some level of architectural foundation to keep them maintainable, so for the Frontend environment. We have come a long way from table-based web design to the current state. A lot of clever technologies and methodologies have been invented that contribute to the initial foundations of the web and have become de-facto standards. Patterns like REST, Progressive enhancement, Graceful degradation, Accessibility, semantics are great goods. Don’t ignore them.

Compatibility

The continuously diverging landscape of devices we have to support, and the ever growing richness of the user interface we have to build in order to server the demanding user’s online responsive experience, is asking a lot of our technologies and us as developers. Old design paradigms like ‘pixel perfect’, ‘page-design’ and ‘wireframes’ don’t fit to this complex new world. They create a lot of friction, don’t ignore.

Future

Don’t think of the future as a goal, but as a process. Not only new technologies are entering our FE world with an amazing speed, but also the way’s we use them do do stuff are. Future in FE terms is now + 3 months. This means we have to be ready to absorb the future by providing flexibility and agility in our FE architecture. One other big threat in regard to future is to use new technologies or methodologies as a goal on their own, instead of means to reach a goal. Don’t let you be influenced by buzz driven people.

Openness

Our frontend environment has always been a very open, easy to use environment with technologies that have a low learning curve and where it is easy to book visible result. FE sourcecode files are easy editable and deployable to any environment, locally or remote.We only need a browser to view the result of our work. This openness has been one of the drivers for the growth and widely use of the web.In fact, anyone can build a webpage. But bit by bit we are raising barricades and thereby influencing the openness in a negative way. Complex tooling, abstractions, automation, mix-ins, etc. are good means to make our daily life easier and add more structure to our environment, but don’t overdo. Don’t make things difficult when they could be easy.

Uncertainty

FE development has always been a discipline with some aspects of uncertainty. The most annoying perhaps has been the deviating level of browser compliance to web standards. But today the most important uncertainty are the things that lay ahead of us. What does our FE future look like. What technologies will arrive and which devices do we have to serve? Will my current knowledge still be sufficient? which developments should i track? All questions that will constantly pop up, every day of your FE life.

Like i told, future is a process. But don’t let this uncertainty scare you. Embrace it, treat it like a gift. Just be sure you have enough flexibility and agility in your architecture, so you can adapt quickly.

3rd party includes, avoid a hangover!

With the ever growing attention for social media, a lot of new SAAS-like solutions for adding additional functionality to a website are conquering the market. Through mash-up constructions, solutions are offered for bannering, widgets and tracking. These solutions often will load static content from a web server owned by the party offering the solution. This static content consist of javascript, css, html and image files.

The advantages of these SAAS solutions like easy integration and a efficient update-model are well known, but there also are some important risk that should thoroughly be evaluated before proceeding with these 3rd party includes.

Because 3rd party includes are loaded from a domain other than the origin of the actual HTML document, the browser will default to the same-origin-policy handling. This policy for example won’t allow these 3rd party scripts to use XHR for sending client data back to the 3rd party server. In a lot of situations, this same-origin-policy will be circumvented by creating hacks using browser flaws. As a result, these hacks will allow the 3rd party scripts to:

- Instantiate browser plugins
- Open popup windows
- Submit forms
- Use client side storage mechanisms like LocalStorage, SessionStorage, Cookies etc.
- Send XHR’s
- Manipulate the DOM of the origin page
- Use HTC’s and Binary behaviors or bind data

An other known side effect of 3rd party includes are the so called 4th party includes, when SAAS solution providers also include external resources in their sources. These could be for example libraries from a CDN or other delivery network. This construction can introduce some nasty effects that will influence the overall quality of our websites and applications.

Performance

3rd and 4th party content owners can have a different regime or strategy in terms of caching and performance than you try to strive for. Poor or no cache settings and a poor optimization for file size and amount of io of the external sources can result in a bad overall performance of our systems. Any downtime of this external environment or resulting 500 or 404 responses even can block or stall the render-thread of the browser (white screen). The result can be an introduction of SPOF (Single Point Of Failure) on the frontend.

Privacy

3rd party scripts are able to see, store and post everything the user does without any consent of you or the user. Even as a result of the expanding chain-of-trust it will be much harder or even impossible to comply to privacy regulations or perhaps even our own privacy goal. A more for the user visible effect will occur if a 4th party uses click behavior for retargeting purposes.

Security

Because existing browser security policies are bypassed, the risk that the integrity of your systems (websites, applications) is affected, will be increased. Besides the possibility of actual exploits or attacks via XSS, an another great danger is the unnoticed realization of drive-by malware infections because of compromised 3rd and 4th parties. Frequently stories appear in the news about websites been compromised by for example the 3rd party banner network they use. Such latter case is of course extremely damaging to a corporate reputation. As a high-volume site will be popular victims.

Governance / Control

The 4th party phenomenon can result in a mush of sources and origins (domains), where the complexity of the whole increases, and the span-of-control will alarming decrease.

Awareness

To cope with these issues in a sound way, it is important that awareness is created regarding 3rd party includes and the possible risks. A clear vision regarding the above should be formulated and translated into a policy. For example, a thorough risk analysis and assessment could be done. And when necessary some quality requirements could be issued through SLAs with the 3rd party. There are some interesting technically developments going on to deal in a professional way with the same-origin-policy issue when embedding 3rd party content. Things like CORS, CD Messaging and HTML5 Sandbox will in the near future be good solutions to these problems, but until then, risks should be reduced otherwise.

Frontend Trends & Predictions for 2013 (and beyond)

Happy new year to you all!

A new fresh year is ahead of us. A year that will bring a lot of new stuff to our ever dynamic FE world. I took some time to evaluate last year and have a peek into the overwhelming world that will arive soon. Here some of my thoughts for 2013!

1. Responsive (Web) Design will evolve into Adaptive Systems.

Responsive design has been quite a good catalyst for introducing adaptive layout based web design to a broad audience. But when translating responsive design to a scalable and future-proof solution for a enterprise environment, responsive design as defined by using media-queries, a fluid grid system and flexible images won’t cut the cake. A more mature, on adaptive systems based approach, will replace the adaptive design approach. These adaptive systems will consist of a client agnostic interface, context-aware design and adaptive content providers (ACP’s) or adaptive content delivery clusters (ACDC’s).

2. Letting the grid go

Responsive design is strongly connected with the use of css grid systems to structure the layout of our content en UI elements. It allows flexibility and encourages correlation between page elements. But is is still thinking from a page-design focus and it even has some print design characteristics. There will be a shift from traditional grid-systems to more flexible and future proof solutions. New approaches to this subject like frameless grid and the goldilocks approach already have seen the light. Eventually a more holistic approach of laying-out web elements is needed.auto-layout systems will be introduced that define layout constraints on component level and use a constraint satisfaction system that arranges the elements in a way that most closely meets the constraints.

3. MV* Fatigue

Using one of the MV* family patterns is very popular today in creating client-side applications. And with that a lot of new MV* frameworks are popping up. Like Addy Osmani stated in this blogpost, “This overwhelming growth of MV* frameworks will lead to a lot of frustration and confusion with developers”. The ‘Yet Another Framework Syndrome’, or YAFS will also take place on this front. People are abusing the MV* patterns and end up with a chaotic mess while aiming for more structure. There is also a lot of difference in interpretation how a scalable JavaScript application should be organized. MV* frameworks are not matured enough yet. They still don’t address any kind of application layer, communication between Views. There is also a need for other patterns/logic like application initializer, region management, view management etc..

4. More sensor data available in browser

With the growing adoption of web-apps on mobile the browser will silently integrate with de device it’s OS. More and more sensor data from our devices will be routed to the browser through an API. This info can be used in our mobile web-apps to create a lot of rich functionality that currently only can be created with native apps. Geodata from gps and wifi, data from Accelerometer, Gyroscope, Magnetometer, network information, access to local files are already available in the latest mobile/os combinations. Access to captured media and realtime camera access will quickly follow. Eventually device sensors data will be integrated into the DOM with their own objects and events. The introduction of new types of sensors in our handhelds will reveil more and more about the user his context. And this context can be used in our future adaptive designs.

5. FE Cyber security

Whit the rapid growth of cybercrime and the countermeasures know as cyber security, there is also a big shift in focus from backend systems to the client-side environment. Browsers are often misconfigured, allowing malware to get onto a user’s system, stealing credit card data and passwords. Also the weakest link in the encryption chain is the browsers memory or DOM. This often will be the only place where heavily encrypted data will be stored decrypted. That’s why you will see RAM scraping more commonly now as attackers focus on client-side attacks, shifting away from server-side attacks. Also the inevitable expanding world of mobile, device and social integration and the growing technical complexity of client-side technologies like HTML5 and javascript will provide new attack surfaces with a lot of new vectors. Companies will organize from incident response teams to full time dedicated teams for fighting cybercrime and ensure cyber security. These teams will introduce new roles like Forensic Analysts, and Reverse Engineering Malware Specialists, but there will also be a new role for a Frontend cyber specialist. This will be a Frontend specialist with a dedicated Cyber security knowledge, who will reverse engineer Malware, Trojans and will build client-side countermeasures. Still a niche, but with a lot of potential.

6. The introduction of new devices types.

After the huge growth of mobile devices over desktop last year ,new device-groups will apear, also they will blend in more in daily life than we are used to with our handhelds.
The paradigm shift in computing that we see happening now is not only bringing us new types of devices, but also will introduce new ways of interaction and interfacing. Computing has evolved from the mainframe to the desktop to the shoulder bag to the pocket, and now computing is taking over new frontiers: Our physical bodies and the physical environments we inhabit. Two new families of devices will evolve. The wearables are devices that are worn in or on the body. Embedded devices are ‘dumb’ devices that have been made smart by integrating sensors and all forms of data-communication These new types of devices will expand our device-landscape and will eventually use our (adaptive) content and apps.

7. The rise of Micro Apps

With the growth of wearable devices the rise of a new ecosystem will occur Small, wearable, connected devices bring personal content to your wrist, your belt, your helmet, your eyeglasses, your car, your bicycle handlebars. The application that live on these devices are called Micro Apps. Micro Apps have limited screen estate and need their specific approach in UX-design. Development platforms for micro apps have already appeared and will grow.

8. More new and smarter sensors will be embedded

Our portable devices will become more and more aware of it’s user and the surrounding or context. Our mobiles will be stuffed with a lot of new and smarter sensors. These sensors will allow our devices to hear, sea, taste and smell ! The context-aware smartphone will know, for example, if the user is seated and skip location services updates. If it is in a pocket it prevents inadvertent pocket dialing. Also the integration of e-Health sensors will allow our device to continuously monitor the most important biometric parameters of it’s user. It will be aware of the current physical state of the user. All this information will enrich the context profile of the user, and that will allow us to create new smarter interfaces and experiences for our apps and websites.

9. A new era for web-design

The design for our future web will strongly be influenced by the rise of responsive and adaptive interfaces and ever growing and diverging landscape of devices. These new aspects force us to rethink web-design We will need to let go the page-based design thinking and need to search for more modular ways of constructing web-views for our user. New touch patterns will become standard ways of navigating our content. For example, horizontal and vertical scrolling through swiping will become a standard way of navigation. The omni-channel and multidevice landscape will introduce more complex UX-patterns with a transparent and layered interface with multiple views. Visually there will be more room for simplicity and breathing space. The button will be re-invented and full page mood images will disappear. Subtle colored panels, more font types, icons and less images will introduce a new visual era.

10. Breaking out of the browser

The browser will not longer be the only interface for showing web-based applications. With the release of chrome packaged apps you will be able to create desktop apps that won’t need a browser to start, but are totally created with HTML, javascript and CSS. The packaged apps can have access to a lot of OS resources that are yet not accessible through the browser. Packaged apps also can more easily be build for offline use. Some HTML5 frameworks like KendoUI and AppJS already have support for building these packaged apps. The attention chrome packaged apps will encourage other browser vendors to pickup their packed app initiatives again and release their own solutions on short term. Packaged apps are the future of ‘desktop’ apps, written in plain web technology and ready to run everywhere.

A new year, a new blog!

Welcome to my new blog!

After putting some thoughts on paper about the architectural side of frontend (FE), i claimed the domain frontendarchitecture.org in 2008 with the idea to share knowledge and discuss our FE discipline with others. Then i got busy with lots of other stuff…

Now, with the start of a new year, a professionalized FE world, and the very dynamic, complex and teasing playground of tomorow, i think the time is right to start this blog.

This won’t be a blog about implementing FE stuff. It won’t house a lot of code or step-by-step instructions. It will more be a place of posing statements and ideas, discussing and teasing about the foundations of our FE environment.

I hope you will join and share your thoughts too by discussing on topics!