26 Aug 2015, 09:30

Around the Web - August 2015 - ES6/ECMAScript 2015 & Premium Media

Javascript

Welcome to ES6 In Depth! In this new weekly series, we’ll be exploring ECMAScript 6, the upcoming new edition of the JavaScript language [Note : ES6 was approved as ECMA-262, 6th Edition, ECMAScript 2015 Language Specification mid June 2015]. ES6 contains many new language features that will make JS more powerful and expressive, and we’ll visit them one by one in weeks to come. But before we start in on the details, maybe it’s worth taking a minute to talk about what ES6 is and what you can expect.

Xebia published (in French) a PDF about ES6 with a card system. Each card wil present the old and new way to code javascript and provide explainations.

Premium content

  • Streamiing media on demand with Media Sources Extensions : where you will learn how to get rid of Flash and old streaming mechanism and use new features built-in HTML5. A sample will also show you on how to prepare your video for streaming in the browsers. Media source extensions (MSE) are about adaptive bittrate streaming in order to display and brodcast video in your browsers in a smooth way.
  • Moving to HTML5 premium media : Microsoft Edge Team introduces how they plan to implement MSE in their browser, with also some samples and explainations.

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.

23 Apr 2014, 09:30

Web Roundup - 23/4

This blog is not (yet) dead ; some links :

  • Internet Explorer Web Platform Status and Roadmap : To know if/when some features of HTML5/CSS3/JS have been implemented in Internet Explorer from IE9 to "Under Consideration" or "Not currently planned"
  • If you want to build Windows 8 apps in JS (instead of .net technologies) but also more general UI in HTML/CSS/JS (more sceptical on this one), you may be interested by WinJS, recently opensourced by Microsoft. You can even try it first and then look at the code/project.
  • HTML5 Security Cheat sheet : some security points to have in mind
  • WTF, HTML and CSS? : Reasons HTML and CSS might make you say what the fuck. A curated list of commonly frustrating HTML and CSS quandaries, miscues, and dilemmas.
  • A "Should I use" in French about some ergonomic pitfalls like caroussel, intrusive pop-in, fixed headers/footers, etc with samples. Still work in progress but with some good examples.

Till next time !

29 Jan 2014, 09:30

HTML5 Desktop apps

Back in May 2013 was published : HTML5 apps on the desktop in 2013. In the article, the author review the existing solutions which allows to build apps on the desktop that will use HTML/CSS/JS. It reviewed the existing solutions and quickly evaluated them.

8 months later :

  • Sencha product is discontinued, App.JS is dead, TideSDK seems also to be almost dead
  • Node-webkit seems still ongoing ; which seems to mix Node.JS and Chromium (and not webkit). It should provide a good mix
  • Bracket-shell on which is based the Brackets IDE built with HTML/JS/CSS  by Adobe ; not sure on how it can be used on a wider extend (out of Adobe's context). Maybe there are good things to get from it ?
  • Windows 8 will allow HTML/CSS/JS apps as native apps but it may be too specific to W8 ?
  • Ubuntu seems to have a Runtime based on Cordova/PhoneGap to build native apps ; As for W8 above, if it's too tied with Ubuntu, it may not be worth and also Cordova/PhoneGap is still mobile focused.

So at this point, node-webkit seems to most agnostic and universal solution for desktop oriented apps.

I was quite surprised that Chrome Apps or Firefox Apps were not mentionned at this point. Indeed for me, it's the first solution that came to my mind when I think about it : these browsers are cross platform (mobile, tablet, PC, TVs), render HTML/JS/CSS for ages. Firefox had a previous experiences about app outside the browser with XULRunner. Adobe AIR could have been mentionned too ; there was a rise of Air Apps some years ago, seems the enthusiasm vanished in the meantime ?

Beyond node-webkit, two trends to build native apps on the desktop : extending the browser to the desktop or extending the mobile to the desktop, with some common actors on both sides.

And you, how do you see natives apps built in HTML/CSS/JS coming on the desktop ? Does it make sense for you by the way ?

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.

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 :

02 Oct 2013, 09:30

Web Roundup - 02/10

A bunch of things, not really classified this time :

On Javascript side :

On tools side :

  • Google just released a new WYSIWYG authoring tool called Web Designer ; so far I always remained far away from such tools (remember  Dreamweaver in the early 2000s ?), but first feedback seems positive so far. Even Mozilla evangelist Christian Heilman is positive about it.
  • If you are a Raspberry Pi owner, you can also have a look at another Google's project called "coder". It aims to make you learn about web development.
  • The top 25 (responsive) design tools : a bunch of tools to ease the way you will build your site, not all are about responsive and can be used for "traditional" needs or not only for responsive designs.
  • Telize is a JSON IP and GeoIP REST API for IP Geolocation : This service offers a REST API allowing to get a visitor IP address and to query location information from any IP address. It outputs JSON-encoded IP geolocation data, and supports both JSON and JSONP.
  • Jq, a lightweight and flexible command-line JSON processor.

On HTML/CSS side

On tests side :

  • Test first : you could sum up the article with You should write tests. You should write tests first. You should write clean tests first! and test are specs (as in the RSpecs language where tests can be read as a specification)

On webperf side :

One day I hope I'll have enough time to write about AngularJS, Web Components Grunt/Yeoman and ElasticSearch, which I find promising and interesting, but need some time to dive in.

29 May 2013, 23:03

Web Roundup - 29/5

Some links I found interesting :

  • 5 HTML5 Features you need to know :
    • DNS prefetching so that the browser will resolve DNS before you try to access resources from one of this domain (browser will keep it in its cache)
    • Link prefetching : to load in background other pages of your site to render quickly pages
    • Download attribute to force a file to download without going to the required page
    • Regular expression to validate content in the browser, no longer need javascript or server side code to validate user's content in a form
    • Datalist element to implement autocomplete without jquery or some server side actions.
  • ScreenSiz.es : to get extract sizes from popular smartphones, tablets and monitors ; even if it's not recommended to use defined size but use viewport, it may be useful in some cases.
  • Smartphone browser : localStorage is up to 5x faster than narive browser cache : where you can learn that localStorage, part of the HTML5 storage API and designed first to make data resilient, could be use to fasten your website. Control of localStorage is also easier than browsers cache which is shared with other websites, etc. There are some limitations and caveats (at the end of the article) you need to take into account but benefits seems very interesting.
  • Even it's still early alpha, Google released Polymer which is a library built on top of Web Components which is also quite new but with the idea to create its own component and the related html markup. For example, you could create a "bill" object with some attributes and the related rendering. It's more the future than anything else, but it can give you some idea on where we are going.
  • To know more about web components, from Google IO 2013, you can watch :
  • If you want to know where we are going, you can also watch from Google IO 13 : A more Awesome Web : features you have always wanted + slides ; but take care for some of them, support is at very early stage and sometimes it's more POC than anything else (position: sticky for example)
  • A funny one as last one : how to keep up to date on frontend technologies ? :-)

28 Feb 2013, 21:54

Forms in HTML5 - New attributes review

HTML5Doctor published an article on HTML5 forms introduction and new attributes ; which is in fact an except from the book "Beginning HTML5 & CSS3 : The web evolved"

The following attributes are being reviewed with examples and some tips & tricks or examples about their implementation ; some properties were implemented with javascript in the past, now you can do the same in full html5 :

  • placeholder : display some (helpful) text as long as field is empty
  • autofocus : when form is displayed, cell with autofocus is the 1st to be filled
  • autocomplete : allow/disallow autocomplete in forms based on the previous input you made
  • required : mark input field as required
  • pattern : allow to define a regexp pattern against which the input will be validated
  • list & datalist : it can be seen as an improved implementation of select/option
  • multiple : allow to manage a 1-n sequence of field : ex you can have a form with 1 to n email field to invite people with n being dynamic.
  • form : defied at a field level, will define to which form the field is related to
  • formaction : specifies the file or application that will submit the form but defined at a <input type=submit> or <input type=image> level.
  • formenctype : specifies how data will be encrypted but defined at a <input type=submit> or <input type=image> level.
  • formmethod : specifies the method used (GET/POST/PUT/DELETE)  but defined at a <input type=submit> or <input type=image> level.
  • formtarget :specifies the target window for the form results

You can see some other attributes like on the HTML5 Form attributes from W3Schools ;

  • novalidate, formnovalidate about input field validation,
  • min/max or step to manage range of date / numbers
  • height/width about input field size

If you add all this new with also the new input types attributes (email, image, date, range, etc), HTML5 forms are a significant improvement over forms we know today. The only limit so far is the implement of all these new standards in the modern browsers ;-)

[Edit 1] : Regarding the new attributes for input tpyes in form for HTML5, HTML5Doctor.com published a 2nd article after this one introducing these new attributes with an associated demo => HTML5 Form input types

[Edit 2] : Read also the "New guide to the new HTML5 form input types"

17 Jan 2013, 09:43

What if your next backend application would be only an API ?

Web site and application used to be built as following :

  • On the server side, you had all the data, all the logic (what to display and when) and at the end, the server push the answer
  • On the client side (ie in a browser mainly), you only have the rendering of the data and the layout (HTML/CSS/Javascript) - client side allows just to interact with the server side and get/do what you expect. If you go offline but keep your browser open, you cannot do anything with your website or app.

So we all know client/server apps.

Now, for a few years, we have a rise :

  • SaaS services (Flickr, Delicious, Salesforce, etc)
  • Web 2.0 and the mashups effect : you want to retrieve on one page your latest photos, aside your latest marks or latest custom requests, all coming from differents places

That's only feasible thanks to API, which allows interactions between some services/softwares over the net and retrieve data you will aggregate and use as you like.With an API, you can get / create / update / delete data in a system.

Going a little bit further over the years, we got mobile apps, HTML5 and Javascript :

  • Mobile apps, which are on the client side and are able to get data from somewhere over internet and display what you expect and of course manage some offline features so thar you app may work even if you have no connections.
  • HTML5 and its ability to provide especially some local storage and offline management, with a consequence that you can do more on client side, as for mobile.
  • Javascript :
    • Note : if for you Javascript means some crappy visual effects from the early 2000s, just forget this vision. Javascript evolves a lot on the last years, is far more robust than you exepct (but still hase some drawbacks as any language) and can now work both on client and server side. I will not enter into detals here but consider it as a real language as you do for Java, PHP, etc.
    • So Javascript will still provide you all the interaction you need on client side to interact with your application.
    • Have a look at AngularJS or BackboneJS which are HTML/JS framework to build web apps, on client side. See the AngularJS demo app you will build during the tutorial. Everything is done on client side, including search / sort, getting phone list and displaying phone details. For data, there are a few JSON files to provide data in a structured way.

The consequence of this shift is that you can move all or part of the logic on the client side. You only need to be able to fetch/retrieve your data over the network, then apply the logic and render the content & layout to the user on client side, whatever it is a browser, a mobile phone.

So let's imagine you plan to build a new application and know that you will have several devices to support, you could change the architecture as follows :

  • On backend side, just define an API to expose your data as you will use them, with some authentication & authorisation of course
  • On client side (web / mobile / ...), build an app/web app that will connect to your API and consume the data and render it as expected.

In a article in French called "From mobile to web" where the same principe is used (API on one side to provide data and a web app on client side), it even goes one step further by imaginting a single app that will autodetect if you use a mobile or desktop browser and then render the appropriate display. I'm not convinced it's the best solution as it could make your code quite messy.