Archive | Musings RSS feed for this section

Les lieux familiers (bis)

21 Feb


Je voyage assez souvent (et c’est chouette) et me trouve à l’aise dans les aéroports. Quelque chose de familier, d’interchangeable, qui me sied. 

On n’a pas besoin d’y parler trop. C’est reposant. On s’y perd rarement sauf happé dans des rêveries. J’ai un bon bouquin et quand je ne lis pas, j’observe les gens. 

Je regarde souvent ma pellicule photos de téléphone intelligent : il est claffi de photos prises d’avion ou d’aéroport. 


Je suis en transit pour Berlin. Je n’y ai jamais mis les pieds ! On le dit que c’est magnifique et dynamique. J’y vais pour le boulot et prendrai ce que je peux de ces quelques jours. 


Ah, ça va me manquer de moins voyager. 

Les lieux familiers

11 Jan Near Golfito from the plane
Comme moi, Karl est un “hospital native”. Comme moi ? Non, pas tout à fait. Certes en entrant dans un hôpital, comme lui j’entre dans un lieu familier, je comprends les codes non écrits, les habitudes et les processus. Mais point de réconfort n’émerge d’une habitude oubliée. J’ai des habitudes oubliées de mon enfance à l’hôpital (aux hôpitaux, deux, si je veux être précise) car mon papa chef de service y était logé avec nous; et de ma vie de jeune adulte alors que j’y travaillais pendant les vacances scolaires.

Je connais les rotations de gens, les dossiers médicaux, les salles et appareils d’examens, mais ce qui me reste le plus, ce sont les couloirs et coursives aux lumières blafardes, et l’impression déprimante d’un moment en suspens alors que le temps, lui, s’égrène inexorablement. Il me faut un effort pour les occulter et que je fouille pour raviver les sourires des malades, les voix enjouées et le ton rassurant du personnel, et la lumière naturelle inondant les couloirs lorsqu’au profit d’un soin la porte d’une chambre est entrouverte.

Dans ces lieux familiers je ne m’attarde pas.

The best work team

15 Oct

Eiko Nagase writesAny recurring meeting becomes stale over time if left unexamined.” I concur. For the meeting I run every week it’s become a drag after a year or so to even think of building the agenda. For some of the weekly meetings I attend, I sometimes don’t bother reading the agenda.

Eiko compiled a selection of tips to make your meetings less painful, such as changing the dynamics (location, space, time, participants, language, sound, tech) and concludes that “Constant iteration ensures that processes stay fresh and that, on the whole, they improve.

I think ‘constant iteration’ is either aspirational or a waste of time, unless you {are | have a member of your staff} dedicated to monitoring processes. Constantly iterating, if unexamined becomes stale as well. However, it’s healthy and useful to come back to processes, reassess them, and benchmark them against objectives.

hand-drawn illustration of a W3C face to face meeting, in a U-shaped room, showing people around the table in front of laptops, one person at the microphone, and slides projected on a screen

Above is my hand-drawn illustration of a W3C face to face meeting, in a U-shaped room, showing people around the table in front of laptops, one person at the microphone, and slides projected on a screen. This is one of the recurring types of meetings I run, but being part of a distributed team, the majority is weekly teleconferences and one face-to-face per year.

Here are elementary principles that work for me:

  1. Appreciate the people at your meeting and the time they give to your meeting. Your team, your people, your assets, your luck.
  2. Establish goals for the meeting. Building an agenda and sharing it ahead of time is useful. You may build it with your team. Remind your team of the agenda at the start of the meeting.
  3. Take notes, or find a scribe who does. Record salient points, questions, answers, actions and resolutions.
  4. Watch the time and keep to the time. Make sure you give appropriate focus to each item in the meeting docket. Don’t move to a new item without a clear path forward or next steps to the item at hand. If the matter can’t be resolved, state it. Options range from breaking out separately to further brainstorm, take the conversation to e-mail, or simply come back to in the future with fresher information.
  5. For face-to-face meetings, allow for mental breaks and bio breaks. When at a all-day meeting, typically I can focus intensely for 45 minutes or so, after which my brain will go on a break and wander freely for a few minutes.
  6. Don’t ramble. Don’t hog the microphone. Hear all the voices. You may need to tune how you seek feedback so that people feel confident to speak up.
  7. Share notes after the meeting. Executive summaries are valuable additions to meeting notes, especially if your thoughts are orderly and are at ease with words. Otherwise, my tip is to favour taking short notes and summaries, over verbatim records.

Eiko Nagase also advises to alternate technologies used as part of the collaborative work. I concur, with a note of caution: your choices have to take into account the ability of your team and the effort on-boarding them to a new technology requires.

In the case of my team, I chose to alternate between usual means of collaboration such as e-mail, IRC, wikis, and trying out a new thing, Asana, in order to keep my team’s wit sharp and have them step outside of their habits to tackle some projects from a new angle. We use Asana only when it makes a difference and rarely enough that it does. Otherwise it becomes a hassle and defeats the purpose. We’re not quite ready yet to move our work to Github ;)

I’d like to end with a few more tips regarding getting the best from the people you work with:

  • Know your people. Again, your team, your assets, your luck. 
  • Find out where their inclinations, talents and interests reside; use those. 
  • Follow their work, guide them, help them. This is the opposite of micro-management. 
  • Praise their achievements, appreciate and promote their work. 

#ParisWeb 2016: notes and thoughts (day 2)

4 Oct

[Read my notes and thoughts about Day 1.]

I attended Paris Web 2016 on 29-30 September, a two-track conference followed by a day of workshops. I heard about the French Web conference in 2006 for its first edition, but I’ve attended only the last 3 editions. It’s such a great conference. The people are passionate and respectful –no, they are caring and it makes the conference extra special. The staff is dedicated and wonderful. The speakers are excellent. It’s probably the most inclusive conference; as far as I can tell, it’s the only conference that has:

  1. live French sign language,
  2. live translation into French of English presentations, and
  3. transcriptions projected on screen.

In addition, the conferences are filmed for streaming and posterity.

I am not a Web {developer,designer}, but I’m interested for my work in taking the pulse of the Web Community as far as Web Standards are concerned. Each of the two parallel tracks of the conference were appealing and I am looking forward to watching the videos of the talks I could not attend.

Here are my notes and thoughts from the second day:

Web Accessibility

09:00: L’accessibilité décomplexée – ce qu’elle peut faire pour vous. Adoptons un point de vue iconoclaste, voire… totalement décomplexé, sur l’accessibilité !

Par Nicolas Hoffmann

Thoughts:
Nicolas packages accessible plug-ins, shares them on Github, and encourages everyone to do the same. Accessibility brought Nicolas technical knowledge (that should put to rest all the lame excuses from whiners who wait to accrue technical knowledge *before* they think they can tackle accessibility.)
Any contribution is worthwhile and an investment, bound to reap benefits. Nicolas concluded with a question: “What can accessibility do… for you?”
Notes:
from Nicolas’ slides:

  • Evangelise accessibility
    • Avoid negative impressions (e.g. showing demos that fail)
    • Show positive stuff instead
  • Center your vision on “others” rather than “self”
  • Start small (but start)

Static Websites

10:00: Ne passons pas à côté des choses simples. Quels sont les secrets de la vogue pour les gestionnaires de sites statiques.
Par Frank Taillandier et
Bertrand Keller

Thoughts:
Frank and Bertrand held a conversation on stage where one convinced the other that not all data requires a base, and that HTML, CSS and Javascript in some cases can generate simple and light sites that perform well. It’s high time to “Keep It Static Simple”
I used to keep a local diary powered by Blosxom a decade ago and like how simple it was to use from the command line. I then tried Nikola and Pelican several years ago between Christmas and the New Year, determined to change the way I updated my website, but after several days wrestling, I gave up, sad and frustrated. As soon as I can realistically make time, I’ll look again at what generator(s) might be suitable for me.
Notes:
from slides linked off Frank’s article:

  • “serverless” movement
  • some say 80% of the Web does not require any database
  • Static website
  • Contribution, update via a headless CMS (or use an online service)
  • Role of APIs
  • Yet, ‘simple’ does not mean ‘easy’
  • A plethora of generators: Jekyll, hexo, hugo, pelican, brunch, middleman, metalsmith, gatsby, harp, grav, assemble, lekto, roots, nanoc, phenomic, etc.

wysiwyg CSS? holy cow!

11:00: CSS et édition WYSIWYG, l’amour vache. CSS et édition Wysiwyg, c’est l’amour vache. Difficile à implémenter et compliqué à matérialiser en UI. Pourquoi et comment ?
Par Daniel Glazman

Thoughts:
Daniel demonstrated the subtleties around the particular points that make it hard to do wysiwyg CSS.
I believe there are 10 sorts of people. Those who grok CSS and those like me who weep and swear when they have to do some CSS. (Usually the former are quite snotty about that achievement, as they have all the rights to be. R.E.S.P.E.C.T.)
When it comes to CSS, I have no idea what I’m doing. Really. Often do I find myself thinking “hmmm, I have no idea what I’m doing…” but that statement is completely true only as far as CSS in concerned. It’s like I lack the gene to even grasp it. There isn’t one way to do something in CSS, there is *choice*. I would hate it less if I understood why one choice makes sense because $type-here-the-enlightened-wisdom.
The first time I worked in earnest on a style sheet was a fine but cold Sunday in January 2005. It was also the last time. THE DAMN THING TOOK ME 8 HOURS! Behold the comment I left in that style sheet:

/*Here is downtown2.css, a variation of downtown.css
that I made 2 days ago for my W3C People page. As a beginner 
in CSS  I was exposing to a colleague how I wanted images  
to spring out on mouse hover without knowing if that was 
at all feasible ; I was  pointed to http://diveintomark.org/ 
and was told "I think it does  what you want." I was told it 
was a bit tricky. The style at  diveintomark.org is exactly 
the one I was looking for! --05jan2005
"Based on stylesheets from diveintomark.org, copyright (c) 
2004 Mark Pilgrim.  
Used here with permission" 
--memento background-color:
purple: a880bd
rosy: ecdeff--
Opera 7.54u1:mac displays a scaled flower in the top square 
on the left.--09jan2005*/
Then, I discovered Westciv’s *StyleMaster*, a style sheet editor that let me apply sheets to web pages, experiment and debug. Yet, not without great effort –remember the missing CSS gene. I haven’t used it in years, mostly because I no longer have to create style sheets from scratch, but I was thoroughly enthused by it.
My question to Daniel, had I had the time to ask it, “Isn’t Style Master a wysiwyg CSS editor and if so, how does it work around the challenges you exposed?”
Notes:
from Daniel’s slides:

  • [history of wysiwyg]
  • Question about copy/paste: should the style be copied and pasted?
  • What about CSS files that are not local and thus can’t be edited?
  • No FileAPI (File System API is defunct and Web Platform WG might take up work on File API)
  • Conclusion:
    • There is a half wysiwyg CSS editor on the market (BlueGriffon, Daniel’s editor).
    • CSS has been thought for rendering engines but not for editors; and it is not getting any better.
    • There are cases when what to do via a client can’t be done: the user will have to make a choice.

Progressive WebApps

11:45: Progressive Web Apps : le futur du web arrive. Venez découvrir comment le Web peut proposer une expérience proche du natif sur mobile sans les inconvénients des magasins d’applications.
Par Hubert Sablonnière

Thoughts:
Hubert is a great story teller; I loved Hubert’s slides and talk!
Notes:
(slides not found)

  • Desktop vs Mobile vs hybrid apps
  • … Choice depends on context of the user
  • Hubert Sablonnière: “Les URLs, c’est la vie !”
  • New buzzword: Progressive Web Apps (not a new technology but a marketing term)
  • Service Workers – works only in HTTPS
  • See https://pwa.rocks/ (by Opera DevRel)

A11Y beyond reference frames

13:30: Vers l’infini et au delà des référentiels. Les trucs et astuces pour améliorer l’accessibilité de vos sites au delà de la simple conformité RGAA
Par Eric Gateau et
Aurélien Lévy

Notes:
(slides not found)

  • RGAA is not a panacea: test for SVG, Canvas, ARIA only
  • Furthermore, accessibility isn’t just voice over, so RGAA doesn’t cover all aspects of a11y
  • Tests with users
  • Ergonomy
  • Fitts’s law: the biggest and closest the target, the easiest it is to hit.
  • Hick’s law: the time it takes for a person to make a decision as a result of the possible choices he or she has: increasing the number of choices will increase the decision time logarithmically.
  • Gestalt laws: near elements are associated, elements that are alike are associated
  • “When UX doesn’t consider ALL users: “some user experience” = SUX” –Billy Gregory

WCAG.next

13:30: WCAG.next – where do we go from here? Deque System’s Principal Accessibility Strategist John Foliot provides some insights and future milestones towards WCAG.next
By John Foliot

Thoughts:
John gave a well laid-out presentation of W3C Web Accessibility groups current thinking (where ‘current’ dates back a week prior to John’s talk, when the groups met during the W3C TPAC 2016).
One of my take-aways from John’s talk is that Web Accessibility *requirements need to be testable*.
Notes:
(slides not found)

  • Assessment: we need to blend the guidelines from WCAG, UAAG and ATAG
  • Project Silver: AG = Accessibility Guidelines – Decision by the end of 2016
    • https://www.w3.org/WAI/GL/wiki/Designing_Silver
    • Engage broadly, easily and openly
    • Communicate on that effort
    • Define and engage stakeholders
    • Make decisions based on evidence and data
    • Lifecycle (keep the standards Up-to-date)
    • Broaden the scope of applicability
    • Establish clear milestones
    • Likely to take 5-7 years
  • … in the meantime: WCAG 2.x
  • Task forces:
    • Mobile
    • Low Vision
    • Cognitive
  • New Guideline?: Device Manipulation
  • New Success Criteria Requirements:
    1. clear, measurable
    2. Documentation for developers to understand why the requirement exists
    3. At least 1 technique for success