23 Dec 2015, 09:30

Around the Web - December 2015 - AngularJS & AMP

AngularJS

AMP

Google released AMP (Accelerated Mobile Page) which is a subset of HTML to have the minimal formatting for content but possibly with ads and analytics embeded. It aims to speed up the web as Google defined it :

Instant. Everywhere.

For many, reading on the mobile web is a slow, clunky and frustrating experience - but it doesn’t have to be that way. The Accelerated Mobile Pages (AMP) Project is an open source initiative that embodies the vision that publishers can create mobile optimized content once and have it load instantly everywhere.

  • Online advertising - current situation (in French) : A summary to have the whole context on online advertising, the decrease of ads revenues, the rise of ad blockers and the possible alternatives, such as AMP but not only.
  • AMP and Responsive Web Design  : a very interesting article which describe what AMP is and isn't ; in a few words:
    • AMP is more an answer to Facebook Instant's article and apple news
    • APM is strictly performance oriented but not SEO or accessibility oriented
    • It does not threat RWD even if it can show some ways of improvments
  • Why AMP is fast : the article details how in terms of techniques, code and platform, APM is fast. You can take some best practices from it to apply to your websites (when relevant)

27 May 2015, 09:30

Around the Web - May 2015

API

Misc

  • A day at Devoxx France (in French) : a summary from Xebia about the Devoxx France conference (Java based but not only) and their findings.
  • Mix-IT Web was in Lyon in April, and the M6 Web tech team wrote a feedback in French - Day 1 - Day 2 ; it deals both with tech and agile topics.

Browsers

PHP

UX

  • The Apple Watch: User-Experience Appraisal : a review on how you app should behave (or not behave) on the new Apple IWatch ; transition with iPhone is also managed and the way to dealt with content and how you should manage your interactions.

Web performance

NoSQL, ElasticSearch

  • Elastic released a new (commercial) plugin for ElasticSearch caled "Watcher" and which aims to raise "alerts" when some events occured and according to some conditions, it may generate an action (email being sent, interaction with another system, etc).
  • M6 Web Tech team published a video (in French) about an introduction to Cassandra.

Geolocation

  • Indoor geolocation technology : article (in French) about indoor geolocation technology, describing and comparing Wifi vs NFC vs Beacon vs Magnetic field to provide geolocation.

26 Nov 2014, 09:30

Around the Web - November 2014

DNS

HTTPS

MySQL

HTML5/CSS/Responsive Web Design

  • 7 CSS Units you may not know about : rem, vh, vm, vmin, vmax, ex and ch. I did not know the two latter. Some more examples for the vh/vm and vmin/vmax.
  • About rem and em more specially, if you want to move from a fixed approach (ie pixel one) to a more fluid/adaptive one (em/rem), you should read this article  and then this one which explain the issue with pixels and the new way to manage it. You can also use em/rem for positionning content ; em/rem are not only about text.
  • 5 obsolete features in HTML5: hgroups tag, pubdate and scope attributes, command and center elements. With the good way to implement them and/or some workaround if you still need them.
  • RWD adoption 2014 : top 100/1000/10.000 sites are evaluated - from to what extend is RWD implemented to mobile site vs RWD benchmarks in terms of performance.
  • 6 technologies that will change the web platform : asm.js, paralleljs, ECMAScript 6, web components, installable webapps, CSS Grid layout
  • The state of Web Animation 2014 : Between the post-Flash area and the Web Animation API to be implemented in all browsers, a review of current challenges and polyfill to bring animations into the browsers. Comments are also worth to read to get more resources.
  • If you are interested in a book about RWD, seems the latest book from A book apart may interested you : Responsible responsive web design (related review)

Browser

Web Performance

  • M6 Tech team made a review of their participation to Velocity conf (day 1, day 2, day 3), a web performance oriented conference. Even if their synthesis is in French, related slides and video are in English. You can also find the one of 2013 (day 1, day 2, day 3)

AngularJS

React (Facebook)

  • React through the ages : an interesting introduction (from origin to what's coming) about React, a JS library to build user interfaces.

24 Sep 2014, 09:30

Web Roundup - 24/09

Web components

I thought I spoke about them earlier but couldn't find the related post ; so nevermind. Nuxeo (Document & Media Management System) wrote two blog posts so far about how web components could enhance the way we can manage content platform :

More about Web Components.

Tools

  • Microsot to provide IE Web Driver tool for IE11 ; it aims to allow you having automated tests in IE11, simulating user interactions on web pages. Multiple windows, pages, tabs are reported supported !
  • Polyfill Service : The Financial Teams provides a polyfill as a service. Based on user agent, end user will only load in his browser the polyfill that he will require. It avoids modern browsers to load polyfill they do not require. You can also host it on your infrastructure.

Docker

  • Two articles on using Docker on production ; the first one and one of its replies. At least it shows that migrating to docker is not that easy or straight forward. You need to rethink your whole way to manage your infrastructure and the related tools when necessary.
  • You can now even use Docker on your Raspberry Pi. Not sure how much ressources are left for your docker container but there may be some use cases.

Web performance

22 Jan 2014, 09:30

Frontend Review - 22/1

No time yet to focus on my angular app so it will be a frontend review for this week.

  • From the M6 Web Tech Team (in French) : Web performance and disaster case for mobile native applications (but not only) ; the article aims to show 2 things :
    • How they use CharlesProxy to evaluate performance of their apps and get the waterfall of the rendering of their apps.
    • How they use CharlesProxy to simulate bad network conditions (ie throttling) and even some "blackhole" to identify Single Points Of Failure (SPOF) and see also what happens when one of your hosts is down.
  • Adapting to a responsive design (case study) : make some echoes to "Frontend Ops" as they explained their move to responsive design with 5 objectives and how they achieved them :
  1. Speed : Performance affects everyone.
  2. Accessibility :It should work with no styles, backgrounds or JavaScript.
  3. Content parity : The same content and functionality should be on all platforms.
  4. Device-agnostic : Leave no platform behind.
  5. Future-friendly : Cut down on maintenance.

Basically, when an elevator fails, it's useless. When an escalator fails, it becomes stairs. We should be building escalators, not elevators.

In one word : resilience.

15 Jan 2014, 09:30

Frontend Ops
A brilliant article was published mid June 2013 under the title Front-End Ops : by itself, there is nothing new but I really like it because it makes a smart synthesis/wrap-up on some "trends" and the requirement to improve the maturity on frontend side. Below a summary with some inline comments.

Backend is (or should be) quite mature. Even if there are still a lot of things to do, the principles and the tools are there to manage build and deployment process but also production follow-up and performance monitoring. It's just about implementing theses concepts and tools and/or applying them on your projects. We'll suppose now that your backend application is working fine or at least in a decent way.

So what about frontend side (ie what is in the browser ?) ?

A few facts about current situation :
  • More than 80% of the time used to render a page is made on browser side ; so the counterpart is that 20% is made on backend side.
  • Logic is more and more on client side with the rich UI we tend to have
  • When you look at Amazon, a 1% increase in revenue for every 100ms of improved performance.
  • You start to notice the application/web site is slow from a little less than 1 second

So don't you think it's time to invest on frontend side and stop considering that frontend code is just pushed/generated from backend side ?

It's not about focusing on performance. Performance is just a mean to deliver a good user experience and allow end users to use your service/site.

As such, Frontend developpers is not just about putting some HTML/CSS/JS alltogether and manage browser (in)compatibilities. It's even less about backend developers to generate the UI based on some auto-generated code derivated from some models and Java code. It is about to know/understand HTTP principles, how browsers render pages, what to do on backend side to improve frontend performance, etc. It's about going beyond the code to embrace the whole situation/context and deliver the expected UX.

How do we achieve this (non exhaustive list) ?

  • 2013 was the rise of the "frontend tooling chain" with the coming of Bower, Grunt, Yeoman, etc.
  • For years now we have performance tools like Webpage Test, YSlow, PageSpeed, etc
  • Firefox and Chrome DevTools are here for years and were significantly improved over time ; not to mention Firebug,
  • ...
So tools are (almost) there and still need to mature for some of them.

A few more are required :
  • Time to make product owner aware of this challenge and what it costs them not to do it. You don't need to be an Amazon to have benefits to implement it. As long as you have users, you need to provide them a good user exerience if you want your product to be used.
  • Time to make developper aware of this so that they change their habits and embrace this new field.

To conclude with, 3 quotes from the article I really like :

Frontend dev make your apps a reality for end users :

A front-end operations engineer would own external performance. They would be critical of new HTTP requests, and they would constantly be measuring file size and page-load time. [...] . They own everything past the functionality. They are the bridge between an application’s intent and an application’s reality.

Beyond performance, error management and monitoring, it's about providing a resilient system :

A front-end operations engineer would be very friendly with the quality assurance team, and they would make sure that “performance” is a test that comes up green. They’d monitor client-side errors and get alerts when things go wrong. They’d make sure that migrations to new versions of the application go smoothly, and they’d keep all external and internal dependencies up to date, secure and stable. They are the gatekeepers of the application

It's about providing a service to the users and make it using the application on a long term basis :

Not every company or team can afford this person, but even if someone puts on the “front-end operations” hat for one day a week and prioritizes their work accordingly, users win. It doesn’t matter how many features you have or how sexy your features are if they aren’t delivered to the user quickly, with ease, and then heavily monitored. Front-end operations engineers are the enablers of long-term progress.

So I wish it would be part of my job (and yours too) for 2014...

06 Nov 2013, 09:30

Web Roundup - 6/11

Keeping on frontend side to change from my current backend tasks (SSO/Kerberos, Postgresql, etc) :

  • Touch and Mouse : together again for the first time :
    • You may consider so far that your application is either used in a touch context (on a tablet) or a mouse on (on the desktop). However with the rise of Touch & Mouse devices (think Microsot Surface, ChromeBooks, etc), you will have to consider both at the same time.
    • Often developers also consider that mouse and touch events are similar, the article will show you some differences. Fortunately, with Pointer Events initiated by Microsoft, there is a standard in progress for managing both at the same time through a standardised API.
    • You can start using Pointer Events with these JS libraries : PointerEvents.js and Hand.js
  • Icon & Pictogram (in French) : a very interesting article to distinguish icons / pictograms and the right way to use them. Not as obvious as we may think first. A good pictogram = icon illustrating the right concept in the right context, being meaninful for most people with/without the associated label, etc.

  • Reminder : do not use @import to load your css files ; prefer the link notation as files would be downloaded in parralel and not one after another.
  • Still about webperf, a "latency for dummies" article to learn more about latency (what is it ? how it impacts my site ? etc.)
  • And to finish, if you want to hightlight differences between HTML4 and HTML5, there is an app a web page for that.

30 Oct 2013, 09:30

Web Roundup - 30/10
  • A placeholder is not a label (English version | French version) : even if placeholder can looks as a substitute for labels in forms and allow you to win some space, you have to remember that once a content is filled in the column, you loose the mention and thus this item in the form has lost its context.
  • Best of both world - mixing HTML5 and native code : a long article which tries to find the "best of breeds" approcha between HTML5 and native apps with samples / best practices.
  • Responsive typography : how to learn how to make your content readable and adapted in size/height/... by adopting relative unites and not fixed ones.
  • Mobile first responsive web design : review / best practices / tools to implement a mobile first and responsive webdesign project and with the question of performance in mind
  • Breaking the 1000ms mobile bareer : from 1s, user can change his mind and is waiting for your app. So you need to go below this threshold. Slides describe the different ways to get there.

16 Oct 2013, 09:30

Paris Web 2013

I had the opportunity to attend Paris Web last week. For those who don't know Paris Web, it's a conference about webdesign, accessibility and quality, but not only/strictly and 2013 was the 8th edition, gathering 600 people in Palais Brongnart and almost 600 online too with the live. All the conferences were recorded, so if you are interested, you'll be able to watch them online later.

For me, It was 2 days with a lot of insights, values and beliefs on what the web should be and how we should work and somehow live with the Web.

Below a summary of the talks I attended.

Day 1:
  • "La folle journée ou la fourberie d'un projet" : a funny introduction with a story with all the "clichés" about a web project : use of trainee, lack of specs, lack of organisation, etc.
  • "API Best practices" by Eric Daspet (slides) : Eric provides some feedbacks about his own exprience on builind API ; a few lessions he learnt and shared :
    • Dates are ambigous, especially when you deal with timezones ; be the most defensive as you can against date (don't assume lazy people will provide UTC based date for example but more a local date with timezone)
    • Plan additional langues to avoid breaking your JSON object and more globally your API when adding a new languages
    • Pagination : your collection can change between two requests ; so implement a strict filter and some before/after pagination than using offset and limits/quantity
    • Enforce pagination and limits to avoid a client making a query on the whole collection
    • Versioning : be compatible but not that much. You will fail to some extend, assume you will have to redesign your API and have a v1, v2, etc
    • Structure : be predictible with your URI schema ; don't have more than 3 levels (collection / item / link)
    • Encoding : avoid special characters to avoid some double encoding in some code (yours or the one of your client)
    • Security : never implement your own system, rely on standards like HTTP-Baisc and oAuth ; provide a mandatory SSL/TLS channel.
    • Make your API simple to start with but the most flexible/opened also to be easily extended later
    • Mix a bunch of state of the art, standards and pragmatism to have the right balance to build your API
  • "I code so I test" :
    • Remember that Ariane 5 rocket exploded for a cost of 370 millions $ for a code from Ariane 4 which was not tested and for a test estimation about 300.000$
    • Review of the main tools for testing (unit / integration / functionnal / UI / validity / compatibility testing)
    • Aim is not to improve code quality by the test ifself but the process it requires
    • Imrprove code resilience, maintenance and evolutivity
    • Imrpove the trust you have in the code, even if you are not the one who developed it
    • There is a learning curve which is not that much about the tools but about the experience on how/what to test
    • Be realistic/pragmatic in your tests but always tests
    • Start better with a wrong test than with none. Never wait for the perfect test and you will improve them over time.
  • HTML5 accessibility (slides) :
    • There is still a long way to go even if browsers do mostly their job. It's because of the WIP status of HTML5 but also the fact that browser are not always connected to the "Assistant tools" to which they should provide information. Even if not up to date, you can check HTML5Accessibility.com.
    • Overuse of "section" tag in HTML5 is what we had with "div" tag in HTML4, whereas "section" are visible in audio system (and not always div, creating too much noise but at least being visible)
    • Aria is to make the bridge for accessibility when native tags are not sufficient. It will use shadow dom
    • Tip 1 : if you use a "section", provide a heading to make your section meaningful for audio/screen reader devices
    • Tip 2 : if you try to enhance some native html tags (like input) to make it looks fine for non paired people, think about accessiblity
    • Tip 3 : Use native html tag instead of Aria components when possible
    • Tip 4 : Do not change/alter native HTML semantics
    • Tip 5 : all interactive ARIA controls must be able to use with keyboard
  • Subtile accessibility :
    • On mobile, you have no keyboard nor short description ("infobulle"). So you need to find alternatives to make your content accessible.
    • Some patterns (navigation, links management, etc) are reviewed with a few tips to improve the accessibility. Some tips can be used also to improve UX for non paired users.
  • Learning to love : crash course in emotional ux design
    • Starts with reminding that design is not just about how it looks like but also how it works (cf Steve Jobs quote)
    • Impaired people have difficulties to choose because of this lack of "emotion".
    • Before an application can create an emational relation with user, it must meet basic needs first.
    • It's not because a product is useful that a product is usable.
    • When for email you use the "no-reply@domain.com", you just say you users you don"t care about them ; you should better use a please-reply@domain.com
    • Introduce emotional design smoothly with a progressive adoption, starting by fixing an issue so that you have a first rolling point for emotional design.
  • A small step for "em", a big step for the Web by Nicolas Hoizey (slides)
    • Start with a reminder that we should allow user to set his own preferences (font size, etc) to adapt the site to its needs, and thus we need to give them control on the site but with keeping the control on main layout.
    • For these need, please enter "em"  (and "rem") units both for font-size but also for vertical and horizontal grid. Idea is to adopt proportional/relative size and adopt the elastic rendering (which is not the same as fluid which was more a fixed side but set in percentage)
    • If you also mix an "em" approach with responsive web design, you should both offer a good accessibility and user experience with an adaptated rendering.
    • Promotion of the Future Friendly movement, which I'm also really fan about and share the vision of the web.
  • Impactful user experience user strategy : thoughts about UX based on a delivery issue use cases, making think about the whole process and the vision of each participants and how it impacted the whole user experience.
  • HTML5 Javascript API : based on a memo game html/js/css based, the author introduced some CSS/JS/HTML5 - I did not find it that interesting but maybe because it was end of the 1st day.

Day 2 :

  • Adaptive images for responsive webdesign : a review of some techniques to make adaptive images and for each of them a review in termes of performance, complexity (use of dependencies, etc). We can conclude so far that there is no obvious solution and that so far you need to find the solution adpated for your needs. So it's still a nightmare to some extend for a frontend developer and the fact that CMS would also have to manage it for end contributors, is another challenge.
  • Integration, the "it depends" universe (slides) : Frontend devs needs to know from day 1 the requirements and the constraints of the project to make the right assumptions on how they will integrate the site at a HTML/CSS/JS point of view and choose the right solutions. The latter you provide information/constraints to him, the more impacts it can have.
  • Retroactions loops or how to customise your application :
  • Think Mobile UX (slides) : a very interesting talk on mobile UX by focusing on "degrated" moments (when waiting, when out of connection, etc)
    • Challenge : need to think about interruption and breaks, with a requirement of efficiency, on a short and narrow screen
    • Work on the waiting time the user felt and not the real waiting time to allow him keeping focus on his task and without making him angry about your app. like trying to provide an app skeleton to make feel the app is loading, or provide first local features or assume your connection and transaction will succeed and provides an immediate feedback and do the transaction asynchronously (like when the like is displayed in instragram)
    • Focus on the main task of the app to make it damend simple and fask. Secondary task can then be sub-optimised
  • Rusy web (slides) : a "philosophical" talk about data resilience, what should be kept/deleted, who should do that, etc. More open questions than anything else but an interesting talk as the web is only 20 years. What may seem useless now may be useful later for historians but you also have the privacy issues and your digital legacy.
  • Designing with sensors, creating adaptive experience
    • Not really related with web topics but was very interesting especially for the issue it raised about use of data, if robots could make human dumb, etc.
    • Adaptive design is to make a user experience dependant on context and user (so it's not responsive design)
    • Sensors and related intelligence start to be everywhere from Google Now to your Heating system sensors or if you enter a shop, your device would awake, open the app of the shop and become a personnal shoping assistant.
  • Mobile and accessibilty, a trojan game (slides) :
    • Accessibility aspect of projects were often neglected making the assumption impaired people were not using your website.
    • When you look closely to mobile web, it makes us feel as impaired people. So web mobile is a great opportunity to make site accessible by meeting the mobile requirement
    • Tip : if you allow transaction on mobile, increase session and use local storage to allow people to go through their transaction even if they are disturbed or punctually disconnected
  • Paradox of choice :
    • The more choice you have, the more disappointed you will be. Indeed the right choice seems impossible to make. For e-commerce, you need then to filter/sort/narrow user's choices to make him chose the right solution for his needs.
    • Tip : instead of suggesting similar products for which you can create a higher deception, better suggest additional products.
    • Focus on the end of the transaction process to provide a feeling of satisfaction ; what happens before does not matter that much
  • Lighning talks session (people to present 1 topic in 4 minutes)
    • Two devs from Microsoft made two live coding talks with the BabylonJS framework, one to show how to implement a tetris game in HTML/JS/CSS and one about building a first version of the solar system. It was really impressive !
    • I stopped to save the world : what happens when you stop being a hero in all your projects and that even if it may explode to some extent, gains are higher than keeping being a hero both for you and your firm and projects.
    • Others were nice but not that worth to be mentionned :)


What I liked by attending Paris Web :

  • It makes you think about your job, your values/beliefs, your vision of the Web. I should definitely have attended earlier and I need to find how to stay close to these microcosm/universe to sustain skills/values/beliefs.
  • Some topics seems very far away from my current challenges but who knows...
  • It confirms/extend your knowledge on some topics but also let you discover new ones

Videos of each conferences should be available soon - I strongly encourage you to watch them and attend the 2014 edition.

Extra resources :

12 Jun 2013, 23:10

State of the Responsive Web Design (RWD)

A brilliant article on the state of RWD and its French translation ; as stated in the article :

In this article, we will look at what is currently possible, what will be possible in the future using what are not yet standardized properties (such as CSS Level 4 and HTML5 APIS), and what still needs to be improved. This article is not exhaustive, and we won’t go deep into each technique, but you’ll have enough links and knowledge to explore further by yourself.

Topics covered in article :

  • Status of the images with the issue of quality and performance,
  • The layout, ie how can we render the "same page" in different devices,
  • End of pixel based design with the use of viewports instead,
  • Typographiy,
  • Form management,
  • Table management,
  • iFrame management,
  • Video management,
  • Navigation,
  • Touch capabilities,
  • and a few others.