3499 stories
·
2 followers

"Looks Good to Me"

1 Share

pro $24.99 per month

  • access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
  • share your subscription with another person
  • choose one free eBook per month to keep
  • exclusive 50% discount on all purchases

lite $19.99 per month

  • access to all Manning books, including MEAPs!

team

5, 10 or 20 seats+ for your team - learn more


Deliver code reviews that consistently build up your team and improve your applications.

“Looks Good To Me” offers a unique approach to delivering meaningful code reviews that goes beyond superficial checklists and tense critical conversations. Instead, you’ll learn how to improve both your applications and your team dynamics.

“Looks Good To Me” teaches you how to:

  • Understand a code review's benefits and process
  • Build an objective code review practice
  • Clarify responsibilities: reviewee, reviewer, and team lead/manager
  • Establish manageable guidelines and protocols
  • Automate code quality with linting
  • Compose effective comments
  • Combine reviews with pair programming, mob programming, and developer rotations

This one-of-a-kind guide comes from expert author, instructor, and international speaker Adrienne Braganza, who has spent 10 years pioneering her thoughtful, empathetic approach to code reviews. Inside, you’ll find comprehensive coverage of every part of the code review process, from choosing a system to keeping reviews manageable for everyone involved.

about the book

“Looks Good To Me” is a comprehensive guide to code reviews. It’s perfect for any stage of your process—whether you’re improving your practices, setting up a new review system, or even hearing about code reviews for the very first time. The book’s flexible practices are designed to flex to suit how your team does things. Each chapter offers multiple options and solutions, relatable scenarios, and personal tidbits from Adrienne’s career—plus starter templates that let you apply what you’ve learned straight away.

This book’s focus on team happiness and collaborative processes ensures you’ll be constructive in your code review comments, collectively design standards and procedures, and keep reviews focused on the code rather than the developer. With this mix of tools, processes, common sense, and compassion, you’ll run a highly effective review process from first commit to final deployment.

about the reader

For any developer or engineering lead that wants to establish or enhance how they perform code reviews.

about the author

Adrienne Braganza a software engineer, keynote speaker, author of the best selling book Coding for Kids: Python, and a LinkedIn Learning instructor who has taught over 65,000 learners.

table of contents

You can see this entire book for free. Click anywhere in the table of contents to start reading

detailed TOC

Part 1: What’s a code review?

Part 2: Code review foundations

Part 3: Building a better code review

Part 4: Pairing code reviews with other practices

9 Code reviews and pair programming

10 Code reviews and mob programming

11 Code reviews and developer rotations

Appendixes

Appendix A: Template: Starter Emergency Playbook

Appendix B: Template: Starter Team Working agreement

Check your email for instructions on downloading "Looks Good to Me".
Send this story to NewsBlur
Shared stories are on their way...
Read the whole story
emrox
3 hours ago
reply
Hamburg, Germany
Share this story
Delete

Flexible Schemas Are The Mindkiller

1 Share
Read the whole story
emrox
4 hours ago
reply
Hamburg, Germany
Share this story
Delete

Call My Cell

1 Comment and 3 Shares
'Hey, can you call my cell?' '...I'm trying, but it says this number is blocked?' 'Ok, thanks, just checking.'
Read the whole story
emrox
23 hours ago
reply
Hamburg, Germany
Share this story
Delete
1 public comment
JayM
1 day ago
reply
Yeah, from iPhone Newsblur, can no longer see the alt text with light/hard press like before.

I still miss the alt text bot.
Atlanta, GA
HannesL
1 day ago
I also miss alt text bot!
wffurr
1 day ago
Worked for me just now.
benyafai
23 hours ago
Works for me too.
karmakaze
21 hours ago
alt="'Hey, can you call my cell?' '...I'm trying, but it says this number is blocked?' 'Ok, thanks, just checking.'"
lshillman
20 hours ago
It's been broken for me on Android too, but your comment inspired me to see if updating the app fixed it—it did. ...And then as soon as I posted this comment, it stopped working again. 🤨
JayM
14 hours ago
So I used to get the ALT TXT whenever I long pressed on the cartoon inside of NewsBlur. Now I only get the “Zoom, etc” menu, without the alt text on top like before.
JayM
14 hours ago
I do get an on_hover here on the website in Firefox.
JayM
14 hours ago
Super werid. I subscribe to my own Blurblog... for that share, the hover works fine, but not for the original image from my xkcd subscription... weird. Maybe Randall adds the alt text after initial publishing and the fetch happens before that and then caches it... then when I reshare it fetches a fresh version? I give up.
ackyshake
7 hours ago
What works for me is to switch between Story and Text, and then long pressing when in Text mode. It doesn't work for me under Story mode for some reason ¯\_(ツ)_/¯

Learn to Read Korean in 15 Minutes

1 Share
Read the whole story
emrox
2 days ago
reply
Hamburg, Germany
Share this story
Delete

Vanilla JavaScript, Libraries, And The Quest For Stateful DOM Rendering

2 Shares

In his seminal piece “The Market For Lemons”, renowned web crank Alex Russell lays out the myriad failings of our industry, focusing on the disastrous consequences for end users. This indignation is entirely appropriate according to the bylaws of our medium.

Frameworks factor highly in that equation, yet there can also be good reasons for front-end developers to choose a framework, or library for that matter: Dynamically updating web interfaces can be tricky in non-obvious ways. Let’s investigate by starting from the beginning and going back to the first principles.

Markup Categories

Everything on the web starts with markup, i.e. HTML. Markup structures can roughly be divided into three categories:

  1. Static parts that always remain the same.
  2. Variable parts that are defined once upon instantiation.
  3. Variable parts that are updated dynamically at runtime.

For example, an article’s header might look like this:

<header>
  <h1>«Hello World»</h1>
  <small>«123» backlinks</small>
</header>

Variable parts are wrapped in «guillemets» here: “Hello World” is the respective title, which only changes between articles. The backlinks counter, however, might be continuously updated via client-side scripting; we’re ready to go viral in the blogosphere. Everything else remains identical across all our articles.

The article you’re reading now subsequently focuses on the third category: Content that needs to be updated at runtime.

Color Browser

Imagine we’re building a simple color browser: A little widget to explore a pre-defined set of named colors, presented as a list that pairs a color swatch with the corresponding color value. Users should be able to search colors names and toggle between hexadecimal color codes and Red, Blue, and Green (RGB) triplets. We can create an inert skeleton with just a little bit of HTML and CSS:

See the Pen Color Browser (inert) [forked] by FND.

Client-Side Rendering

We’ve grudgingly decided to employ client-side rendering for the interactive version. For our purposes here, it doesn’t matter whether this widget constitutes a complete application or merely a self-contained island embedded within an otherwise static or server-generated HTML document.

Given our predilection for vanilla JavaScript (cf. first principles and all), we start with the browser’s built-in DOM APIs:

function renderPalette(colors) {
  let items = [];
  for(let color of colors) {
    let item = document.createElement("li");
    items.push(item);

    let value = color.hex;
    makeElement("input", {
      parent: item,
      type: "color",
      value
    });
    makeElement("span", {
      parent: item,
      text: color.name
    });
    makeElement("code", {
      parent: item,
      text: value
    });
  }

  let list = document.createElement("ul");
  list.append(...items);
  return list;
}
Note:
The above relies on a small utility function for more concise element creation:
function makeElement(tag, { parent, children, text, ...attribs }) {
  let el = document.createElement(tag);

  if(text) {
    el.textContent = text;
  }

  for(let [name, value] of Object.entries(attribs)) {
    el.setAttribute(name, value);
  }

  if(children) {
    el.append(...children);
  }

  parent?.appendChild(el);
  return el;
}
You might also have noticed a stylistic inconsistency: Within the items loop, newly created elements attach themselves to their container. Later on, we flip responsibilities, as the list container ingests child elements instead.

Voilà: renderPalette generates our list of colors. Let’s add a form for interactivity:

function renderControls() {
  return makeElement("form", {
    method: "dialog",
    children: [
      createField("search", "Search"),
      createField("checkbox", "RGB")
    ]
  });
}

The createField utility function encapsulates DOM structures required for input fields; it’s a little reusable markup component:

function createField(type, caption) {
  let children = [
    makeElement("span", { text: caption }),
    makeElement("input", { type })
  ];
  return makeElement("label", {
    children: type === "checkbox" ? children.reverse() : children
  });
}

Now, we just need to combine those pieces. Let’s wrap them in a custom element:

import { COLORS } from "./colors.js"; // an array of { name, hex, rgb } objects

customElements.define("color-browser", class ColorBrowser extends HTMLElement {
  colors = [...COLORS]; // local copy

  connectedCallback() {
    this.append(
      renderControls(),
      renderPalette(this.colors)
    );
  }
});

Henceforth, a <color-browser> element anywhere in our HTML will generate the entire user interface right there. (I like to think of it as a macro expanding in place.) This implementation is somewhat declarative1, with DOM structures being created by composing a variety of straightforward markup generators, clearly delineated components, if you will.

1 The most useful explanation of the differences between declarative and imperative programming I’ve come across focuses on readers. Unfortunately, that particular source escapes me, so I’m paraphrasing here: Declarative code portrays the what while imperative code describes the how. One consequence is that imperative code requires cognitive effort to sequentially step through the code’s instructions and build up a mental model of the respective result.

Interactivity

At this point, we’re merely recreating our inert skeleton; there’s no actual interactivity yet. Event handlers to the rescue:

class ColorBrowser extends HTMLElement {
  colors = [...COLORS];
  query = null;
  rgb = false;

  connectedCallback() {
    this.append(renderControls(), renderPalette(this.colors));
    this.addEventListener("input", this);
    this.addEventListener("change", this);
  }

  handleEvent(ev) {
    let el = ev.target;
    switch(ev.type) {
    case "change":
      if(el.type === "checkbox") {
        this.rgb = el.checked;
      }
      break;
    case "input":
      if(el.type === "search") {
        this.query = el.value.toLowerCase();
      }
      break;
    }
  }
}
Note:
handleEvent means we don’t have to worry about function binding. It also comes with various advantages. Other patterns are available.

Whenever a field changes, we update the corresponding instance variable (sometimes called one-way data binding). Alas, changing this internal state2 is not reflected anywhere in the UI so far.

2 In your browser’s developer console, check document.querySelector("color-browser").query after entering a search term.

Note that this event handler is tightly coupled to renderControls internals because it expects a checkbox and search field, respectively. Thus, any corresponding changes to renderControls — perhaps switching to radio buttons for color representations — now need to take into account this other piece of code: action at a distance! Expanding this component’s contract to include field names could alleviate those concerns.

We’re now faced with a choice between:

  1. Reaching into our previously created DOM to modify it, or
  2. Recreating it while incorporating a new state.
Rerendering

Since we’ve already defined our markup composition in one place, let’s start with the second option. We’ll simply rerun our markup generators, feeding them the current state.

class ColorBrowser extends HTMLElement {
  // [previous details omitted]

  connectedCallback() {
    this.#render();
    this.addEventListener("input", this);
    this.addEventListener("change", this);
  }

  handleEvent(ev) {
    // [previous details omitted]
    this.#render();
  }

  #render() {
    this.replaceChildren();
    this.append(renderControls(), renderPalette(this.colors));
  }
}

We’ve moved all rendering logic into a dedicated method3, which we invoke not just once on startup but whenever the state changes.

3 You might want to avoid private properties, especially if others might conceivably build upon your implementation.

Next, we can turn colors into a getter to only return entries matching the corresponding state, i.e. the user’s search query:

class ColorBrowser extends HTMLElement {
  query = null;
  rgb = false;

  // [previous details omitted]

  get colors() {
    let { query } = this;
    if(!query) {
      return [...COLORS];
    }

    return COLORS.filter(color => color.name.toLowerCase().includes(query));
  }
}
Note:
I’m partial to the bouncer pattern.
Toggling color representations is left as an exercise for the reader. You might pass this.rgb into renderPalette and then populate <code> with either color.hex or color.rgb, perhaps employing this utility:
function formatRGB(value) {
  return value.split(",").
    map(num => num.toString().padStart(3, " ")).
    join(", ");
}

This now produces interesting (annoying, really) behavior:

See the Pen Color Browser (defective) [forked] by FND.

Entering a query seems impossible as the input field loses focus after a change takes place, leaving the input field empty. However, entering an uncommon character (e.g. “v”) makes it clear that something is happening: The list of colors does indeed change.

The reason is that our current do-it-yourself (DIY) approach is quite crude: #render erases and recreates the DOM wholesale with each change. Discarding existing DOM nodes also resets the corresponding state, including form fields’ value, focus, and scroll position. That’s no good!

Incremental Rendering

The previous section’s data-driven UI seemed like a nice idea: Markup structures are defined once and re-rendered at will, based on a data model cleanly representing the current state. Yet our component’s explicit state is clearly insufficient; we need to reconcile it with the browser’s implicit state while re-rendering.

Sure, we might attempt to make that implicit state explicit and incorporate it into our data model, like including a field’s value or checked properties. But that still leaves many things unaccounted for, including focus management, scroll position, and myriad details we probably haven’t even thought of (frequently, that means accessibility features). Before long, we’re effectively recreating the browser!

We might instead try to identify which parts of the UI need updating and leave the rest of the DOM untouched. Unfortunately, that’s far from trivial, which is where libraries like React came into play more than a decade ago: On the surface, they provided a more declarative way to define DOM structures4 (while also encouraging componentized composition, establishing a single source of truth for each individual UI pattern). Under the hood, such libraries introduced mechanisms5 to provide granular, incremental DOM updates instead of recreating DOM trees from scratch — both to avoid state conflicts and to improve performance6.

4 In this context, that essentially means writing something that looks like HTML, which, depending on your belief system, is either essential or revolting. The state of HTML templating was somewhat dire back then and remains subpar in some environments.
5 Nolan Lawson’s “Let’s learn how modern JavaScript frameworks work by building one” provides plenty of valuable insights on that topic. For even more details, lit-html’s developer documentation is worth studying.
6 We’ve since learned that some of those mechanisms are actually ruinously expensive.

The bottom line: If we want to encapsulate markup definitions and then derive our UI from a variable data model, we kinda have to rely on a third-party library for reconciliation.

Actus Imperatus

At the other end of the spectrum, we might opt for surgical modifications. If we know what to target, our application code can reach into the DOM and modify only those parts that need updating.

Regrettably, though, that approach typically leads to calamitously tight coupling, with interrelated logic being spread all over the application while targeted routines inevitably violate components’ encapsulation. Things become even more complicated when we consider increasingly complex UI permutations (think edge cases, error reporting, and so on). Those are the very issues that the aforementioned libraries had hoped to eradicate.

In our color browser’s case, that would mean finding and hiding color entries that do not match the query, not to mention replacing the list with a substitute message if no matching entries remain. We’d also have to swap color representations in place. You can probably imagine how the resulting code would end up dissolving any separation of concerns, messing with elements that originally belonged exclusively to renderPalette.

class ColorBrowser extends HTMLElement {
  // [previous details omitted]

  handleEvent(ev) {
    // [previous details omitted]

    for(let item of this.#list.children) {
      item.hidden = !item.textContent.toLowerCase().includes(this.query);
    }
    if(this.#list.children.filter(el => !el.hidden).length === 0) {
      // inject substitute message
    }
  }

  #render() {
    // [previous details omitted]

    this.#list = renderPalette(this.colors);
  }
}

As a once wise man once said: That’s too much knowledge!

Things get even more perilous with form fields: Not only might we have to update a field’s specific state, but we would also need to know where to inject error messages. While reaching into renderPalette was bad enough, here we would have to pierce several layers: createField is a generic utility used by renderControls, which in turn is invoked by our top-level ColorBrowser.

If things get hairy even in this minimal example, imagine having a more complex application with even more layers and indirections. Keeping on top of all those interconnections becomes all but impossible. Such systems commonly devolve into a big ball of mud where nobody dares change anything for fear of inadvertently breaking stuff.

Conclusion

There appears to be a glaring omission in standardized browser APIs. Our preference for dependency-free vanilla JavaScript solutions is thwarted by the need to non-destructively update existing DOM structures. That’s assuming we value a declarative approach with inviolable encapsulation, otherwise known as “Modern Software Engineering: The Good Parts.”

As it currently stands, my personal opinion is that a small library like lit-html or Preact is often warranted, particularly when employed with replaceability in mind: A standardized API might still happen! Either way, adequate libraries have a light footprint and don’t typically present much of an encumbrance to end users, especially when combined with progressive enhancement.

I don’t wanna leave you hanging, though, so I’ve tricked our vanilla JavaScript implementation to mostly do what we expect it to:

See the Pen Color Browser [forked] by FND.



Read the whole story
emrox
2 days ago
reply
Hamburg, Germany
alvinashcraft
7 days ago
reply
West Grove, PA
Share this story
Delete

Design-Pattern Guidelines: Study Guide

1 Share

Summary:  Unsure how to design and implement user-interface patterns? Use this collection of links to our content about specific patterns.

This article lists some of our content that provides specific guidelines on designing a variety of interface patterns, from toggle switches to navigations tabs.

If you’re new to designing interfaces, check out the 10 usability heuristics for user-interface design, which are foundational principles for interaction design. From there, use the resources below for guidance on designing specific interface patterns.

A Note on Interface Guidelines

After a couple of years, are these guidelines still valid? These usability guidelines are dependent mostly on human behavior, which changes slowly, and a lot less on the specifics of a given technology, which can change quickly. As you adopt the following guidelines in your own work, consider the core user behaviors and usability principles at play (not just the technology). Don’t throw out old findings because of their age.

Input Controls

This section covers input elements like checkboxes, toggle switches, input steppers, and more.

Number

Link

Format

Description

1

Checkboxes vs. Radio Buttons

Article

12 guidelines for when to use a checkboxes and radio button

2

Toggle-Switch Guidelines

Article

Related elements and 4 guidelines for use

3

Checkboxes vs. Switches in Forms

Video

Guidelines for when to use checkboxes and switches in forms

4

Design Guidelines for Input Steppers

Article

Benefits and drawbacks of input steppers along with 8 design guidelines

5

Date-Input Form Fields: UX Design Guidelines

Article

Date-input patterns and 7 design guidelines

6

Split Buttons: Definition

Article

7 tips for designing split buttons

7

Input Controls for Parameters: Balancing Exploration and Precision with Sliders, Knobs, and Matrices

Article

Guidelines for designing specialized, application-specific input controls

8

A Checklist for Designing Mobile Input Fields

Article

14 guidelines for designing mobile input fields

9

Easier Input on Mobile Devices

Video

Design recommendations for input fields on mobile

Forms and Wizards

These resources provide guidelines for designing effective web forms and wizards.

Number

Link

Format

Description

10

Website Forms Usability: Top 10 Recommendations

Article

Well-established but frequently ignored UX design guidelines for web forms

11

How to Report Errors in Forms: 10 Design Guidelines

Article

10 guidelines to help users recover from errors in forms

12

Wizards: Definition and Design Recommendations

Article

Guidelines for designing usable wizards

In this section, we provide resources on tooltips, modal and nonmodal dialogs, popups, and instructional overlays.

Number

Link

Format

Description

13

Tooltip Guidelines

Article

Guidelines and recommendations for using tooltips on desktop sites

14

Tooltips in the User Interface

Video

15

Modal & Nonmodal Dialogs: When (& When Not) to Use Them

Article

Disadvantages and guidelines for using modal dialogs

16

UI Modes and Modals

Video

Modes and modals: definitions and when they may be appropriate

17

Popups: 10 Problematic Trends and Alternatives 

Article

Factors to consider when using popups and realistic alternatives

18

Popup Problems

Video

19

Bottom Sheets: Definition and UX Guidelines

Article

Guidelines for designing bottom sheet overlays that offer contextual details or controls

20

Instructional Overlays and Coach Marks for Mobile Apps

Article

Tips for designing helpful and noticeable instructional overlays

21

Mobile-App Onboarding: An Analysis of Components and Techniques

Article

Guidelines for designing and implementing various types of mobile-app onboarding

22

3 Design Considerations for Effective Mobile-App Permission Requests

Article

Considerations and recommendations for designing dialogs that request mobile-app permissions

Icons and Indicators

This section lists resources relevant to icons and other visual indicators such as progress indicators.

Number

Link

Format

Description

23

Icon Classification: Resemblance, Reference, and Arbitrary Icons        

Article

3 categories of icons and considerations for designing them

24

Icon Usability

Article

UX guidelines to ensure that your users recognize your icons and know what they mean

25

Tips for Icon Usability

Video

26

Accordion Icons: Which Signifiers Work Best?

Article

Research findings and 3 recommendations for using accordion icons

27

Visual Indicators to Differentiate Items in a List

Article

Recommendations for using visual indicators to attract attention to certain list elements

28

Progress Indicators Make a Slow System Less Insufferable.  

Article

Recommendations for communicating system status

29

Mask Interaction Delays with Progress Indicators

Video

30

Skeleton Screens 101

Article

Skeleton screens: definition and benefits of using one

These resources are specific to designing menus like drop downs and mega menus.

Number

Link

Format

Description

31

Menu Design: Checklist of 15 UX Guidelines to Help Users

Article

Guidelines for designing effective menus

32

Navigation Menus – 5 Tips to Make Them Visible

Video

5 design guidelines to increase the visibility of navigation menus

33

Mega Menus Work Well for Site Navigation

Article

Guidelines for designing large navigation menus

34

Dropdowns: Design Guidelines

Article

Use cases and 8 guidelines for dropdowns

35

Listboxes vs. Dropdown Lists

Article

Advantages, disadvantages, and tips for using listboxes and dropdown lists

36

Contextual Menus: Delivering Relevant Tools for Tasks

Article

10 tips for designing effective contextual menus

37

Expandable Menus: Pull-Down, Square, or Pie?

Article

Design considerations for expandable menus

Site Navigation Elements

This list of resources covers a variety of general navigation controls like breadcrumbs, links, and footers.

Number

Link

Format

Description

38

Breadcrumbs: 11 Design Guidelines for Desktop and Mobile.

Article

Insight on presenting breadcrumbs

39

Guidelines for Visualizing Links

Article

Established guidelines for communicating web links

40

Back-to-Top Button Design Guidelines

Article

UX guidelines for back-to-top links that help users navigate long pages

41

In-Page Links for Content Navigation

Article

Guidelines on in-page links vs. accordions and tabs during content navigation

42

Accordions on Desktop: When and How to Use.  

Article

Definition of accordions and when to use them on desktop

43

Accordions: 5 Scenarios to Avoid

Video

44

Accordions on Mobile  

Article

Definition of accordions and when to use them on mobile

45

Accordions on Mobile

Video

46

Tabs, Used Right

Article

12 design guidelines for tab controls

47

Footers 101: Design Patterns and When to Use Each

Article

Common footer components and recommendations on when to use each

48

Mobile Subnavigation

Article

Design recommendations for mobile subnavigation elements

48

Local Navigation Is a Valuable Orientation and Wayfinding Aid

Article

Guidance for designing effective local navigation

49

Infinite Scrolling: When to Use It, When to Avoid it  

Article

When to use infinite scrolling vs. pagination vs. a Load more button

50

3 Alternatives to Infinite Scrolling

Video

51

Vertical Navigation

Video

Insights on showing navigation menu options in a vertical-list format

In-Page Navigation

This list of resources covers in-page navigation controls like scrolljacking and table of contents.

Number

Link

Format

Description

52

Scrolljacking 101

Article

Scrolljacking: definition and best practices

53

Scroll Fading 101

Article

Scroll fading: definition and best practices

54

Table of Contents: The Ultimate Design Guide

Article

Table of contents: placement and styling guidelines

55

Table of Contents on Mobile

Video

Guidelines on designing table of contents on mobile

Search

In this list, we provide guidelines for visualizing and communicating search components.

Number

Link

Format

Description

56

Search: Visible and Simple

Article

Foundational search design principles

57

Site Search Suggestions

Article

Tips for designing the search feature on your site

58

Designing Search Suggestions

Video

59

3 Guidelines for Search Engine “No Results” Pages

Article

Tips for turning zero search results into an opportunity for content discovery

60

The Magnifying-Glass Icon in Search Design: Pros and Cons

Article

11 recommendations for designing with the magnifying-glass icon

61

Intranet-Search Essentials

Article

11 design practices on intranet-search and how to assess its success

62

Enriched Site-Searc3h Suggestions: Rarely Used

Article

Common implementation issues with enriched search suggestions

Errors

This list of resources covers a variety of guidelines around error messaging and how to design interfaces to prevent users from making errors.

Number

Link

Format

Description

63

Error-Message Guidelines

Article

Guidelines for designing error messages that are visible, respect users and provide constructive communication

64

An Error Messages Scoring Rubric

Article

65

Hostile Patterns in Error Messages

Article

Guidelines to avoid overly aggressive error prevention and recovery

66

Error Handling on Mobil Devices: Showing Alerts

Video

Pitfalls of using alert dialogs to signal errors on mobile devices

67

Confirmation Dialogs Can Prevent User Errors - If Note Overused

Article

8 recommendations for using confirmation dialogs to prevent user errors

Privacy and Ethics

This list of resources covers a variety of guidelines around design interfaces that follow ethical practices and respect user privacy.

Number

Link

Format

Description

68

Cookie Permissions 101

Article

Guidelines for designing cookie permission overlays that respect user privacy and are user friendly

69

Passwordless Accounts: One-Time Passwords (OTPs) and Passkeys

Article

Password developments making login and registration easier and quicker

70

Passwordless Accounts

Video

71

Deceptive Patterns in UX: How to Recognize and Avoid Them

Article

Deceptive patterns: definition and how to avoid them

72

What Makes a Dark UI Pattern

Video

Read the whole story
emrox
2 days ago
reply
Hamburg, Germany
Share this story
Delete
Next Page of Stories