Jump to content

User:Pablo Grass (WMDE)/conferences/IJS2020 Munich/day2

From Wikitech

How UX saves Devs Time, Money, and Sanity, Debbie Levitt, @Delta_CX

  • attendance: 64
  • the perspective on UX's place in agile processes (and how the are often misunderstood and brushed over)
  • devs want to be involved early in feature concepts, so do UX people want to stay involved once development took off
  • 4 horsemen of bad UX, we try to avoid - use these handles to point out problems in your daily work
    • frustration
    • confusion
    • disappointment
    • distraction
  • advocates for research of user needs (in a qualitative fashion) as a foundation for all following steps
  • differentiates between UX (e.g. cognitive psychology) and UI (e.g. typography) tasks, the qualities needed in people who work in those jobs
  • "Just ship it"/"Fail fast", testing concepts on the public (even a percentage) - i.e. rushing into guessing what people need - is not wise strategy
  • better follow a UX process which prevents code being written (waste) for concepts which contain defects - in private is a better place to fail (not visible to customers, the competition)
  • sounds like the opposite of what popular companies (claim to) do, but - when unpackaging your latest iPhone - did you feel like they did the least they could do and try it in public? Not so much.
  • ideas about UX involvement in the agile process and how SAFe for lean enterprises gets it wrong
  • instead suggests that
    • a UX person should be part of every feature team as a representative and connection to other UX specializations
    • if dev expects a backlog of read-made stories, then UX must be 4-6 week ahead development to have time to research before coding starts
  • counters the argument "that's not agile" argument
    • goal is a well-oiled machine, a great assembly line
    • UX work is a prerequisite for development, the same way ready made code is a prerequisite for QA to assess its outcome
  • stop burning money on guess work
  • test integration as in "customer paths", not according to technical perimeters
  • emphasizes the value in the "work not done", which can be the result of UX stopping work on a feature which will not work (to avoid the "cost of poor quality")
    • internal costs, e.g.
      • delays
      • morale
    • external costs, e.g.
      • complaints
      • loss of sales
  • suggests to use KPI to justify the time spent in UX phases, e.g. customer complaints, ...
  • also emphasizes that the term UX must be used correctly: sticking a label on something is not a solution, need to hire the right people, too
  • Q: "When UX is 4-6 weeks ahead of development, what happens when the design can't be done for some technical resons or would be to expensive to implement? When would you notice this?"
    • A: a problem is that UX and dev people don't talk. Usually there is a disconnect. There should be a regular communication where UX can validate that early ideas they have can technically be built - during early concept phase. UX people should schedule them. If that does not happen, dev should create the pull. This is not approval, but advice.
  • Q (myself): "Design Systems (tokens et al.) are a recent trend. How do you perceive their impact on the collaboration between UX and dev?"
    • A: "Great questions. Some quick answers! I'm very for design systems for a large number of reasons. I'll be releasing a Medium article about that hopefully next week. It will improve collab, but mostly between visual designers and front-end devs. I'm sometimes not that involved in that, as a non-artist!"
  • Q: "Also what do you think about API first approach ?"
    • A: "API first doesn't totally make sense to me. If it's really first, how did we know we needed a new call or API? :) Hopefully we did some qualitative research to learn what customers and devs needed. So research first, decisions, architecture, API. :) Or what did you mean? :)"
  • Q: "We often face the issue that we get a wireframe but it isn't always clear which data is shown in which case. Let's say there is a filter showing, how do you explain within your design how every filter should function for example ?"
    • A: "It's easy for me to show that since I normally build Axure prototypes. You'd get a clickable interactive prototype and some notes. You can click the filter and see how it appears and works. A great UX designer will know that they have to design that. They can't just give you a filter button and you guess from there. Sorry you might have a UX worker who was being a bit lazy there!"

Advocacy for agile (in the positive sense) work with a valid reminder to all that taking time to think in advance does not go against that. Waiting for that medium article.

Have Your Cake and Eat it Too: GraphQL? REST API? Maybe You Can Have Both!, Roy Mor, @roymortech

  • attendance: 27
  • chose graphql upon an infrastructure overdo
    • listened to the internet
    • liked that it is client-centric - over/underfetching are no longer a problem
    • great developer experience, no more gluing together or filtering responses
  • 3rd parties requested programmatic access to the data - but they insisted on a REST API (for valid reasons)
  • challenge: keep the internal graphql API but expose a REST API with the same functionality
    • develop and maintain the functionality twice was deemed wasteful and irresponsible
  • https://github.com/sisense/graphql2rest is the outcome, as also described here
  • 10 minutes in dives into implementation details
    • can also rename parameters
  • taking a step back, which tech to use today to implement a public API?
  • few good slides TODO with a comparison; e.g. reasons against graphql
    • lack of need for complex queries
    • caching requires extra (client) libraries
    • error handling not using HTTP standards
    • much fewer convention
    • all public, does not lend itself to "sensitive queries"

Build graphql, expose REST? It's possible. He did it, see README, carry on.

Offline First: The Mobile First of PWAs, Sebastian Springer, @basti_springer

PWAs still don't seem to be mainstream, the trend curve has moved along and people are starting to use it for use cases where they actually make sense - with robust tooling and libraries.

Management Brainfucks in komplexen Digitalprojekten, Fabian Ziegler

  • attendance: 16
  • explains how project specification changed over the years
  • complexity in projects increased (heterogenous tech stacks, ...) while need for flexibility increased
    • V olatile
    • U uncertain
    • C chaotic/complex
    • A mbiguious
  • needs new answers
    • estimates
    • complexity
    • methodology
  • mentions pareto principle
  • mentions Brook's law and how he fell for it
  • mentions iron triangle (features, price, deadline) and how clients' needs some level of confidence of what they will get for their money and new pricing models (agiler Festpreis)
  • methodology-wise those new challenges need new answers, not answers which worked in the past
    • the management perspective needs to transition to become client-centric as well
  • Q: "Anekdotisch: Wie lange dauert es bei euch im Schnitt vom ersten Kundenkontakt bis zur ersten geschriebenen Zeile code?"
    • A: Ironically with bigger customers, commitment is usually quicker. The Mittelstand is usually a hard sale

Eloquent and agreeable but a chain of buzz words no less. Could not draw conclusions for the daily life from it ("it's complicated").

The New CSS Logical Properties, Elad Shechter, @eladsc

  • attendance: 32
  • writing-mode property, controlling the "block axis" and the scroll direction
  • direction property, controlling "inline axis"
  • so far we have been using "physical properties" according to the default direction in which websites are working (as in English)
  • we need to update our thinking to understand "logical properties"
  • mentions Traditional Japanese and Mongolian (for writing mode vertical-rl and vertical-lr respectively)
  • puts emphasis that this is not only about left and right, but top and bottom as well - and consequently affects width and height as well
  • explains how the "inset-" prefix fixes a CSS sin from the past, being able to express an intent with one property (previously 4: left, right, top, bottom)
  • anything that has x and y axis will have to see an update
  • flexbox and grid were already written in logical thinking - so they don't need new thinking (if you have internalized how they work already)
  • suggests that updating an existing project to "logical" is all but impossible
  • shorthands (e.g. "margin") are bust and a solution is work-in-progress
  • apparently is the person how suggested the "flow-mode" property https://github.com/w3c/csswg-drafts/issues/1282#issuecomment-443253091
  • logical properties are still not supported in media queries, which is a problem for responsiveness according to the height in case of 90° rotated pages
  • Q (myself): "What's your prediction. Will implementation in the physical way go away in the next 5 years?"
    • A: Most websites will be in logical properties in 5 years, for sure. Browsers will support physical forever.
  • Q: "We are currently starting to build a new business application. Do you see reasons not to use logical properties from the beginning (like older browsers etc) or would you recomment to start with them from the beginning?"
    • A: In this specific second it may be too early because of browser support, but it is changing every month.
  • Q: "how does the writing mode effect grids? I assume they do not automatically rotate as well? Or do they?"
    • A: They are being rotated
  • Q (myself): "Looking at browser support. Can you mention tooling to bring support for the ones _not_ supported yet? (cross-compile it, ...)"

Refreshingly excited take on a topic which will take the web to the next level. Nice seeing we are on top of the curve with wikit on this. Some work is left on our side wrapping our heads around the vertical aspect of this.

Micro-Frontends: A Migration Story, Max Gallo, @_maxgallo

  • attendance: 30
  • first context, then the solution
  • the context
    • scalability - is a key factor with live events (DAZN does sports)
    • company growth - requires teams to be working autonomousy
    • live - "gooooooal" should happen for everyone at the same time
    • competing products - one external, one internal development
  • the problem
    • allow teams to deploy independently from each other
      • create verticals for different business concerns (i.e. users see only one of the micro frontends at a time)
  • migration
  • mentions lambda @ edge - to customize what cloudfront delivers
    • can be put in different spots, modifying "viewer" or "origin" requests & responses
    • explanation of use very close to marketing material
      • regions
      • stickyness
  • work on the CDN is an addition to the traditional view of client & server
  • Q (myself): "Is the split using lambda primarily about making sure everything works, or also about A:B testing?"
    • A: we don't do real A:B testing this way but it's thinkable (I refrained from a follow-up question how they collect data accross regions)

The talk did a very good job at highlighting the context in which a company operates and how that dictates the technological choices. It also provided a few insights into motivations for the use of micro frontends. Beyond that it stayed very high level, iterating over existing commercial solutions and how to marry them.

Passwords are so 1990, Sam Bellen, @sambego

  • attendance: 59
  • intro by a short history of passwords
  • can be augmented by a second factor (e.g. a physical card) for added security, but still are often weak and can get stolen
  • (the usual) good password practices: complex (length beat other factors), random (no personal information), unique (no reuse across services), change frequently
  • bottom line: passwords can be annoying
  • alternatives
    • one time passwords - also often used as a second factor
      • SMS based - interceptible
      • email based - interceptible
      • authenticator apps - based on a shared secret between app and server
    • login via 3rd party (google, social media, ...)
    • web authentication API https://www.w3.org/TR/webauthn/
      • most modern devices (e.g. iPhone) have authenticator device built in already
  • deep dive into YubiKey usage with webauthn
  • does only replace solutions where you currently enter a password yourself, not OAuth and comparable

A less than compelling argument to put convenience over security (all eggs in one basket) and plausible deniability.

Retrieved from "https://wikitech.wikimedia.org/w/index.php?title=User:Pablo_Grass_(WMDE)/conferences/IJS2020_Munich/day2&oldid=1886586"