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 !

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 :

01 May 2013, 22:45

Pagination and View all

Back to ergonomy with an article from last alert from Jabob Nielson called : "Users' pagination preferences and View all" reviewing some pagination use cases and the opportunity of a "View all" feature and of course to save user's preference when you can to avoid poisoning his user experience.

Some examples where pagination is fine like for Search Engine Result Pages ; You don"t consider your users to see all of the pages and you are able to promote the top results to him. Thus, they will limit them to the first pages, when not only the 1st ; to some extend, we could consider that it's useless to compute more than the n first pages..

Some examples where pagination is badly considered :

  • When users may need to see all the content to make his choice and needds to embrace the whole selection to progress in his thinking. Ex for clothers where you want not to see only the 5 first shirts but the whole collection to make your choice between colors.
  • Articles and other linear content flows should never be paginated as breaks are badly considered. Or at least you should provide both views (full & paginated).

View n items vs view all : author would recommend to have a default pagination value and a view all option than to have a "view 10/20/50/100 items". Moreover, the default pagination view and view all will simplify your form management as the choice would be easier thant if you propose multiple pagination steps. Easy filtering is better than complex one.

Of course, the "View all" for performance issue may be limited or being available only when your query is small enough (less than 100 items ?)

Last but not least, once your user chose a preference about pagination, be consistent with it during its session and later if possible so that he does not get lost or will get angry to refine each time his preferences.

22 Jan 2013, 09:46

Auto-Forwarding carousels and accordions annoy users and reduce visibility

Jakob Nielsen just published a very interesting article on  Auto-Forwarding Carousels and Accordions Annoy Users and Reduce Visibility about carousels but also small promo boxes.

Regarding promo boxes :

  • They are considered as ads and thus are ignored by the users
  • Being on the right side is not effcient as main focus is on the left side of the screen
  • Need to have a clear wording to be meaningful

Regarding carousels/accordions :

  • It should stand still to allow users to have the time to read it (think about foreign visitors or low-litteracy users)
  • As it moves automatically, users tend to ignored it as they consider it as an advertisement.
  • User may not see it as other faces of the carousels may hide the content
  • Use a correct wording, here "rewarding lifestyle" or "Siemens appliance" doesn"t mean anything if you are not from Siemens' Marketing Team or worst make people reluctant (I cannot affoard a "Siemens' Applicance")

The main lesson I think is before implementing a trending item (here carousels), think about ergonomy and usability first

03 Jan 2013, 22:54

Forms - Positionning and rendering of action buttons

First of all, happy new year to all !

Today, an interesting blog post on action buttons (Submit / Save / etc) and how you should render them and where you should position them : Pattern UI - Positionnement et aspect des boutons d'action (in French)

Summary :

  • Main action should be on the right side and secondary action(s) on left side ; it's based on screen scanning mechanism
  • Main action should be rendered bigger and in a different way as other actions ; to ease your user's decision and action.

So best ergonomy should be the following one :

form_action.png

For non french readers :

  • Action secondaire = secondary action
  • Action principale = main action

Do you agree with this ? For people who read from Right to Left, would it be the same or the opposite ?

20 Dec 2012, 22:43

Lose that credit card (type) field

Another blog post on ergonomy, with a focus on this stressfull moment of invoice/billing when you need to enter your credit card number in a payment form.

What if you could reduce this stressfull moment and ease your customer's life by removing the "credit card type" field as you can guess it from his credit card number ? It's the purpose of this article : Lose the credit card field

So what you can do :

  1. Remove the credit card type field
  2. Bonus : improve user experience by displaying automatically his credit cart type as long as he types the numbers

examples with empty form :

credit-card-think-geek-initial.png

Once you type a 4 :

credit-card-think-geek-after.png

Once you type 55 :

credit-card-think-geek-after-alternative.png

So of course it means you know the rules to identifiy a credit card type and update it when needed but this would not change every two days ; and if there is an error, remember the The 4 H’s of Writing Error Messages.

To check the numbers consistence without asking the credit card type, you may know the Luhn algorithm.

13 Dec 2012, 22:06

The 4 H’s of Writing Error Messages

After a technical blog post on database, let's change a little bit for ergonomy : error messages are challenging for the User Experience ("An unexpected error occurend" is not the best mesage you could have).

On the UXMas advent calendar, an interesting article was published with the title "The 4 H's of Writing Error Messages" and defining the following rule :

Error messages need to be:

  • Human : error messages should have been writen to be read by humans and not a robot for a robot
  • Helpful : it must be understood by the user  (what went wrong ? how can the user recover ?) but also well presented (think of contrast, layout, etc)
  • Humorous : a touch of humor may help to smooth this moment of stress/disappointment/... but don't be too humourous !
  • Humble : Assume it's not user's fault but your (app or server side) and be humble and mean it. Users are more tolerant when you are transparent/honest with them

Maybe a 5th item which is missing is that you are informed about the issue and that you will investigate user's issue (as long as it's true, remember 4th H). Indeed, being humble and sorry is nice but fixing bugs is better ;-)

07 Dec 2012, 22:42

Responsive Web Design in 10 points

Attached an infography in French about Responsive Web Design (RWD) and 10 points you need to have in mind when you do RWD.

[INSERER IMAGE]

RWD is a set of tools and techniques so that a single website will be visible on all devices, from smartphone / tablets to screens by optimising the rendering depending on screen optimisation. By using RWD, you no longer need to have a dedicated mobile site but it's not as easy as it may seem to make a site full RWD compliant.

A summary for English spoken people :

  1. Simple layout (at least at a code point of view) so that you can adapt easily the layout on the fly depending on screen (resize imagges, change content position, etc)
  2. Use mediaqueries ; they are one of the lever of the RWD. It is directives which basically says : if screen is x width, then display this content with an y size ; See the link to have some examples
  3. Be aware of main resolutions : 480/768/1024 px width for major ones ; you may refine with 320/720/900px - remember that 1024px width is default width size for website being well displayed on desktop PC.
  4. Have a fluid design so that it can adapt to the device it will be displayed on ; it also means that as you drop fixed positionning in favor of relative ones, you will control a little bit less the rendering as you may be used to.
  5. Manage your images : Depending on how you use them, you can resize them or manage a conditionnal display depending on screen resolution (ie display large image on desktop and a smaller ones for lower resolutions)
  6. Set correctly your min/max values to manage efficiently the rendering - for ex, even if your resolution is 2560px large, you can say that your website can have a maximum width of 1024px. Thus, it will not be over-stretched to your amazing screen and display nicdely. Sor for minimum value.
  7. Everything is relative but define it the right way ; Use %age value or use the "em" unit and compute value based on the unit you chose and remains consistent (do not mix % and em for ex)
  8. On mobile, use a single column rendering (but then take care of navigation and so on to ease your User Experience)
  9. Remove non necessary content - focus on the main action of your page
  10. Use the viewport directive to display nicely on the browser as some browser try to simulate the desktop navigation/resolution

I would add a 11th one which would be : never use "User Agent" as it's evil (in French).  to manage how you display your site on a device. Indeed, browser tries to be considered for another ones and cheats to some extend. So you can't rely on this information. Moreover, with the launch of the iPad mini, it's the same user agent as the normal iPad (in French) whereas screen size is definitely not the same...

A more global point on RWD is RWD from a project management perspective (French translation), which I also recommend to read before you want to define your RWD strategy for your next website.

Source : http://www.servicesmobiles.fr/services_mobiles/2012/12/infographie-les-enjeux-et-différents-points-techniques-sur-le-responsive-design.html