10, 2024 (GLOBE NEWSWIRE) — Digital Element, a global leader in IP intelligence and geolocation solutions, today announced that its threat intelligence platform, Nodify, has received a 2024 CyberSecurity Breakthrough Award in the category of Threat Detection Solution Provider of the…

Digital Element’s Nodify Named Threat Detection Solution Provider of the Year from CyberSecurity Breakthrough Awards

Element

element

Enhance Your Code Architecture With SOLID Principles (with Swift Examples)

Building a UDP Server & Client in Swift with Network.framework

Do you know that feeling when you create your own component instead of improving the default HTML components? Your design team created something beautiful, but browsers won't support it out of the box, and fixing it everywhere becomes a nightmare. We all know this pain, but these challenges make our job interesting. Today, I wanted to talk about one pitfall that awaits us during this thrilling journey: the placement of dropdown elements, such as the select menus or the date pickers. Absolutely Wrong At first, it looks like position: absolute solves all our problems, and it does to some extent. But then, modal windows ruin everything. If the dropdown overflows, it gets cut off. Sure, you can scroll down and see it, but you’d better pray that your designer cannot reach you with a sharp object. That’s far from perfect—we can do better. Fix It With 'fixed' If we want to display the content over everything, we need position: fixed. The only problem is that we will lose the parent element coordinates: fixed elements are quite independent by nature. This means the only thing we need to do is determine the exact coordinates of the drop-down element in these situations: When we display it.
When its content is changed.
When we scroll the window and/or the scrollable parent.
When we resize the window and/or the scrollable parent. We also need to decide whether to display it above the toggler if it is too close to the bottom of the screen. Feels doable. I will use Vue.js, but it should be easy to follow even if you prefer React or Angular. Let’s Rock This Joint Here’s the structure we’ll use: export const useDropdownAttributes = () => {
  const dropdownWidth = ref('');
  const dropdownTop = ref('');
  const dropdownBottom = ref('');
  const dropdownLeft = ref('');
  const isDirectedUpwards = ref(false);
  const togglerRect = ref<DOMRect>();
  const dropdownRect = ref<DOMRect>();

  const autodetectPosition = (
    isDropdownDisplayed: Ref<boolean>,
    togglerElement: HTMLElement | null = null,
    dropdownElement: HTMLDivElement | null = null,
    dropdownContent: Ref<unknown> | ComputedRef<unknown> = ref([]),
    isUpwardPreferred = false,
  ) => {
    // ...
  }

  return {
    autodetectPosition,
    dropdownTop,
    dropdownBottom,
    dropdownLeft,
    dropdownWidth,
    isDirectedUpwards,
    togglerRect,
    dropdownRect,
  };
}; There are four variables for the dropdown position plus the isDirectedUpwards flag and a function that updates them all. We also return two variables for the toggler’s and dropdown’s Rects: this might be convenient, for example, for the tooltips that need to be aligned to the middle of the content. As you may remember, we also need to handle the scrolling and resizing of the scrollable parent, so let’s create a function to find it: const getFirstScrollableParent = (element: HTMLElement | null): HTMLElement => {
    const parentElement = element?.parentElement;
    if (!parentElement) return document.body;

    const overflowY = window.getComputedStyle(parentElement).overflowY;

    if (overflowY === 'scroll' || overflowY === 'auto') return parentElement;

    return getFirstScrollableParent(parentElement);
  }; Now, let’s add the main function: const autodetectPosition = (
    isDropdownDisplayed: Ref<boolean>,
    togglerElement: HTMLElement | null = null,
    dropdownElement: HTMLElement | null = null,
    dropdownContent: Ref<unknown> | ComputedRef<unknown> = ref([]),
    isUpwardPreferred = false,
  ) => {
    if (!togglerElement || !dropdownElement) return;

    const updateDropdownAttributes = () => {
      togglerRect.value = togglerElement.getBoundingClientRect();
      dropdownRect.value = dropdownElement.getBoundingClientRect();
      dropdownWidth.value = `${togglerRect.value.width}px`;
      dropdownBottom.value = `${window.innerHeight - togglerRect.value.top}px`;
      dropdownTop.value = `${
        window.innerHeight - togglerRect.value.bottom - dropdownRect.value.height
      }px`;
      dropdownLeft.value = `${togglerRect.value.left}px`;
    };

    const handleResize = () => {
      requestAnimationFrame(updateDropdownAttributes);
    };

    const handleScroll = () => {
      requestAnimationFrame(updateDropdownAttributes);
    };

    watch(
      [isDropdownDisplayed, dropdownContent],
      ([newVal, _]) => {
        const scrollableParent = getFirstScrollableParent(togglerElement);
        if (!newVal) {
          window.removeEventListener('resize', handleResize);
          window.removeEventListener('scroll', handleScroll);
          scrollableParent.removeEventListener('resize', handleResize);
          scrollableParent.removeEventListener('scroll', handleScroll);
          return;
        }

        requestAnimationFrame(() => {
          const distanceFromBottom =
            window.innerHeight - togglerElement.getBoundingClientRect().bottom;
          const distanceFromTop = togglerElement.getBoundingClientRect().top;
          const dropdownHeight = dropdownElement.offsetHeight;

          isDirectedUpwards.value = isUpwardPreferred
            ? distanceFromTop > dropdownHeight
            : distanceFromBottom < dropdownHeight &&
              distanceFromTop > dropdownHeight;

          updateDropdownAttributes();
          window.addEventListener('resize', handleResize);
          window.addEventListener('scroll', handleScroll);
          scrollableParent.addEventListener('resize', handleResize);
          scrollableParent.addEventListener('scroll', handleScroll);
        });
      },
      { deep: true },
    );
  }; We pass isDropdownDisplayed and dropdownContent so we can react to their updates. We also pass togglerElement and dropdownElementwhich we need to calculate the position. Finally, there’s isUpwardPreferred in case you want the dropdown above the toggler by default. Time to Relax and Enjoy In your component, you will need something like this (I assume you have added refs to your toggler and dropdown in the template): const {
  autodetectPosition,
  dropdownTop,
  dropdownBottom,
  dropdownLeft,
  dropdownWidth,
  isDirectedUpwards,
} = useDropdownAttributes();

const togglerRef = ref<HTMLElement>();
const dropdownRef = ref<HTMLElement>();

const isDropdownShown = ref(false);

onMounted(() => {
  autodetectPosition(isDropdownShown, togglerRef.value?.$el, dropdownRef.value?.$el);
}); And the CSS will look like this: .dropdown {
  position: fixed;
  bottom: v-bind('isDirectedUpwards ? dropdownBottom : dropdownTop');
  left: v-bind('dropdownLeft');

  width: v-bind('dropdownWidth');
  min-width: 0;
} Voilà. The dropdown is displayed properly even when overflowing and moves above the toggler if there isn’t enough space below. And since we’re at the end of the article, I’d love to leave you with something cheerful—but I’m out of ideas. So, I'm afraid "good luck" is all I have this time. Good luck. 👋 You can find the complete code on GitHub. Do you know that feeling when you create your own component instead of improving the default HTML components? Your design team created something beautiful, but browsers won't support it out of the box, and fixing it everywhere becomes a nightmare. We all know this pain, but these challenges make our job interesting. Today, I wanted to talk about one pitfall that awaits us during this thrilling journey: the placement of dropdown elements, such as the select menus or the date pickers. Absolutely Wrong At first, it looks like position: absolute solves all our problems, and it does to some extent. But then, modal windows ruin everything. position: absolute If the dropdown overflows, it gets cut off. Sure, you can scroll down and see it, but you’d better pray that your designer cannot reach you with a sharp object. That’s far from perfect—we can do better. Fix It With 'fixed' 'fixed' If we want to display the content over everything, we need position: fixed . The only problem is that we will lose the parent element coordinates: fixed elements are quite independent by nature. This means the only thing we need to do is determine the exact coordinates of the drop-down element in these situations: position: fixed When we display it. When its content is changed. When we scroll the window and/or the scrollable parent. When we resize the window and/or the scrollable parent. When we display it. When its content is changed. When we scroll the window and/or the scrollable parent. When we resize the window and/or the scrollable parent. We also need to decide whether to display it above the toggler if it is too close to the bottom of the screen. Feels doable. I will use Vue.js, but it should be easy to follow even if you prefer React or Angular. Let’s Rock This Joint Here’s the structure we’ll use: export const useDropdownAttributes = () => {
  const dropdownWidth = ref('');
  const dropdownTop = ref('');
  const dropdownBottom = ref('');
  const dropdownLeft = ref('');
  const isDirectedUpwards = ref(false);
  const togglerRect = ref<DOMRect>();
  const dropdownRect = ref<DOMRect>();

  const autodetectPosition = (
    isDropdownDisplayed: Ref<boolean>,
    togglerElement: HTMLElement | null = null,
    dropdownElement: HTMLDivElement | null = null,
    dropdownContent: Ref<unknown> | ComputedRef<unknown> = ref([]),
    isUpwardPreferred = false,
  ) => {
    // ...
  }

  return {
    autodetectPosition,
    dropdownTop,
    dropdownBottom,
    dropdownLeft,
    dropdownWidth,
    isDirectedUpwards,
    togglerRect,
    dropdownRect,
  };
}; export const useDropdownAttributes = () => {
  const dropdownWidth = ref('');
  const dropdownTop = ref('');
  const dropdownBottom = ref('');
  const dropdownLeft = ref('');
  const isDirectedUpwards = ref(false);
  const togglerRect = ref<DOMRect>();
  const dropdownRect = ref<DOMRect>();

  const autodetectPosition = (
    isDropdownDisplayed: Ref<boolean>,
    togglerElement: HTMLElement | null = null,
    dropdownElement: HTMLDivElement | null = null,
    dropdownContent: Ref<unknown> | ComputedRef<unknown> = ref([]),
    isUpwardPreferred = false,
  ) => {
    // ...
  }

  return {
    autodetectPosition,
    dropdownTop,
    dropdownBottom,
    dropdownLeft,
    dropdownWidth,
    isDirectedUpwards,
    togglerRect,
    dropdownRect,
  };
}; There are four variables for the dropdown position plus the isDirectedUpwards flag and a function that updates them all. We also return two variables for the toggler’s and dropdown’s Rects: this might be convenient, for example, for the tooltips that need to be aligned to the middle of the content. isDirectedUpwards As you may remember, we also need to handle the scrolling and resizing of the scrollable parent, so let’s create a function to find it: const getFirstScrollableParent = (element: HTMLElement | null): HTMLElement => {
    const parentElement = element?.parentElement;
    if (!parentElement) return document.body;

    const overflowY = window.getComputedStyle(parentElement).overflowY;

    if (overflowY === 'scroll' || overflowY === 'auto') return parentElement;

    return getFirstScrollableParent(parentElement);
  }; const getFirstScrollableParent = (element: HTMLElement | null): HTMLElement => {
    const parentElement = element?.parentElement;
    if (!parentElement) return document.body;

    const overflowY = window.getComputedStyle(parentElement).overflowY;

    if (overflowY === 'scroll' || overflowY === 'auto') return parentElement;

    return getFirstScrollableParent(parentElement);
  }; Now, let’s add the main function: const autodetectPosition = (
    isDropdownDisplayed: Ref<boolean>,
    togglerElement: HTMLElement | null = null,
    dropdownElement: HTMLElement | null = null,
    dropdownContent: Ref<unknown> | ComputedRef<unknown> = ref([]),
    isUpwardPreferred = false,
  ) => {
    if (!togglerElement || !dropdownElement) return;

    const updateDropdownAttributes = () => {
      togglerRect.value = togglerElement.getBoundingClientRect();
      dropdownRect.value = dropdownElement.getBoundingClientRect();
      dropdownWidth.value = `${togglerRect.value.width}px`;
      dropdownBottom.value = `${window.innerHeight - togglerRect.value.top}px`;
      dropdownTop.value = `${
        window.innerHeight - togglerRect.value.bottom - dropdownRect.value.height
      }px`;
      dropdownLeft.value = `${togglerRect.value.left}px`;
    };

    const handleResize = () => {
      requestAnimationFrame(updateDropdownAttributes);
    };

    const handleScroll = () => {
      requestAnimationFrame(updateDropdownAttributes);
    };

    watch(
      [isDropdownDisplayed, dropdownContent],
      ([newVal, _]) => {
        const scrollableParent = getFirstScrollableParent(togglerElement);
        if (!newVal) {
          window.removeEventListener('resize', handleResize);
          window.removeEventListener('scroll', handleScroll);
          scrollableParent.removeEventListener('resize', handleResize);
          scrollableParent.removeEventListener('scroll', handleScroll);
          return;
        }

        requestAnimationFrame(() => {
          const distanceFromBottom =
            window.innerHeight - togglerElement.getBoundingClientRect().bottom;
          const distanceFromTop = togglerElement.getBoundingClientRect().top;
          const dropdownHeight = dropdownElement.offsetHeight;

          isDirectedUpwards.value = isUpwardPreferred
            ? distanceFromTop > dropdownHeight
            : distanceFromBottom < dropdownHeight &&
              distanceFromTop > dropdownHeight;

          updateDropdownAttributes();
          window.addEventListener('resize', handleResize);
          window.addEventListener('scroll', handleScroll);
          scrollableParent.addEventListener('resize', handleResize);
          scrollableParent.addEventListener('scroll', handleScroll);
        });
      },
      { deep: true },
    );
  }; const autodetectPosition = (
    isDropdownDisplayed: Ref<boolean>,
    togglerElement: HTMLElement | null = null,
    dropdownElement: HTMLElement | null = null,
    dropdownContent: Ref<unknown> | ComputedRef<unknown> = ref([]),
    isUpwardPreferred = false,
  ) => {
    if (!togglerElement || !dropdownElement) return;

    const updateDropdownAttributes = () => {
      togglerRect.value = togglerElement.getBoundingClientRect();
      dropdownRect.value = dropdownElement.getBoundingClientRect();
      dropdownWidth.value = `${togglerRect.value.width}px`;
      dropdownBottom.value = `${window.innerHeight - togglerRect.value.top}px`;
      dropdownTop.value = `${
        window.innerHeight - togglerRect.value.bottom - dropdownRect.value.height
      }px`;
      dropdownLeft.value = `${togglerRect.value.left}px`;
    };

    const handleResize = () => {
      requestAnimationFrame(updateDropdownAttributes);
    };

    const handleScroll = () => {
      requestAnimationFrame(updateDropdownAttributes);
    };

    watch(
      [isDropdownDisplayed, dropdownContent],
      ([newVal, _]) => {
        const scrollableParent = getFirstScrollableParent(togglerElement);
        if (!newVal) {
          window.removeEventListener('resize', handleResize);
          window.removeEventListener('scroll', handleScroll);
          scrollableParent.removeEventListener('resize', handleResize);
          scrollableParent.removeEventListener('scroll', handleScroll);
          return;
        }

        requestAnimationFrame(() => {
          const distanceFromBottom =
            window.innerHeight - togglerElement.getBoundingClientRect().bottom;
          const distanceFromTop = togglerElement.getBoundingClientRect().top;
          const dropdownHeight = dropdownElement.offsetHeight;

          isDirectedUpwards.value = isUpwardPreferred
            ? distanceFromTop > dropdownHeight
            : distanceFromBottom < dropdownHeight &&
              distanceFromTop > dropdownHeight;

          updateDropdownAttributes();
          window.addEventListener('resize', handleResize);
          window.addEventListener('scroll', handleScroll);
          scrollableParent.addEventListener('resize', handleResize);
          scrollableParent.addEventListener('scroll', handleScroll);
        });
      },
      { deep: true },
    );
  }; We pass isDropdownDisplayed and dropdownContent so we can react to their updates. isDropdownDisplayed dropdownContent We also pass togglerElement and dropdownElement which we need to calculate the position. togglerElement dropdownElement Finally, there’s isUpwardPreferred in case you want the dropdown above the toggler by default. isUpwardPreferred Time to Relax and Enjoy In your component, you will need something like this (I assume you have added refs to your toggler and dropdown in the template): const {
  autodetectPosition,
  dropdownTop,
  dropdownBottom,
  dropdownLeft,
  dropdownWidth,
  isDirectedUpwards,
} = useDropdownAttributes();

const togglerRef = ref<HTMLElement>();
const dropdownRef = ref<HTMLElement>();

const isDropdownShown = ref(false);

onMounted(() => {
  autodetectPosition(isDropdownShown, togglerRef.value?.$el, dropdownRef.value?.$el);
}); const {
  autodetectPosition,
  dropdownTop,
  dropdownBottom,
  dropdownLeft,
  dropdownWidth,
  isDirectedUpwards,
} = useDropdownAttributes();

const togglerRef = ref<HTMLElement>();
const dropdownRef = ref<HTMLElement>();

const isDropdownShown = ref(false);

onMounted(() => {
  autodetectPosition(isDropdownShown, togglerRef.value?.$el, dropdownRef.value?.$el);
}); And the CSS will look like this: .dropdown {
  position: fixed;
  bottom: v-bind('isDirectedUpwards ? dropdownBottom : dropdownTop');
  left: v-bind('dropdownLeft');

  width: v-bind('dropdownWidth');
  min-width: 0;
} .dropdown {
  position: fixed;
  bottom: v-bind('isDirectedUpwards ? dropdownBottom : dropdownTop');
  left: v-bind('dropdownLeft');

  width: v-bind('dropdownWidth');
  min-width: 0;
} Voilà. The dropdown is displayed properly even when overflowing and moves above the toggler if there isn’t enough space below. And since we’re at the end of the article, I’d love to leave you with something cheerful—but I’m out of ideas. So, I'm afraid "good luck" is all I have this time. Good luck. 👋 You can find the complete code on GitHub. You can find the complete code on GitHub . GitHub

Proper Display of Custom Dropdown Elements: A How-to Guide

العرض الصحيح لعناصر القائمة المنسدلة المخصصة: دليل إرشادي

Σωστή εμφάνιση προσαρμοσμένων αναπτυσσόμενων στοιχείων: Οδηγός πώς να το κάνετε

Presentación correcta de elementos de descarga personalizados: una guía de cómo

カスタム ドロップダウン要素の適切な表示: ハウツー ガイド

사용자 정의 드롭다운 요소의 적절한 표시: 방법 가이드

Правилно прикажување на приспособени паѓачки елементи: Водич како да се

Pontšo ya maleba ya Dielemente tša go Theoga tša Tlwaelo: Tlhahlo ya Tsela ya go Dira

Prawidłowe wyświetlanie niestandardowych elementów rozwijania: przewodnik

Одговарајући приказ прилагођених падајућих елемената: водич са упутствима

Özel Açılır Öğelerin Doğru Görüntülenmesi: Nasıl Yapılır Kılavuzu

حسب ضرورت ڈراپ ڈاؤن عناصر کا مناسب ڈسپلے: ایک گائیڈ

Developers’ Insights on Game Design Elements: Pros and Cons

Authors:
(1) Clauvin Almeida, Pontifical Catholic University of Rio de Janeiro (PUC-Rio), Rio de Janeiro, Brazil;
(2) Marcos Kalinowski, Pontifical Catholic University of Rio de Janeiro (PUC-Rio), Rio de Janeiro, Brazil;
(3) Anderson Uchoa, Federal University of Ceara (UFC), Itapaje, Brazil;
(4) Bruno Feijo, Pontifical Catholic University of Rio de Janeiro (PUC-Rio), Rio de Janeiro, Brazil. Table of Links Abstract and 1 Introduction 2. Background and Related Work and 2.1. Gamification 2.2. Game Design Elements and 2.3. Gamification Effects 2.4. Related Work on Gamification Negative Effects 3. Systematic Mapping and 3.1. The Research Questions 3.2. Search Strategy and 3.3. Inclusion and Exclusion Criteria 3.4. Applying the Search Strategy 3.5. Data Extraction 4. Systematic Mapping Results 5. Focus Group: Developer Perception on the Negative Effects of Game Design Elements 5.1. Context and Participant Characterization 5.2. Focus Group Design 5.3. The Developers’ Perception on The Negative Effects 5.4. On the Perceived Usefulness, Ease of use and Intent of Adoption of Mapped Negative Effects 5.5. Participant Feedback 6. Limitations 7. Concluding Remarks 7.1. Future Research Directions Acknowledgements and References 5.2. Focus Group Design We carefully designed and performed our focus group by following the guideline proposed by Kontio et al. [107]. Figure 6 depicts the steps adopted throughout the focus group. We organized these steps in three major phases: (1) Preparation for the focus group session; (2) Discussion by group of game design elements; and (3) Discussion on the perception of the mapped negative effects. We describe each phase and step hereafter. Phase 1: Preparation for the focus group session – This phase consists of the collection of preliminary resources for supporting the execution of the focus group session. For this purpose, we follow two steps. Step 1 consisted of recruiting developers with experience in gamification to engage in discussions. As mentioned in Section 5.1, we contacted developers of the VazaZika development team for participating in our study. We obtained the acceptance of four developers via Consent Form in which we explain our research goals, information about the waiver statements, and that the information provided by each participant will be treated confidentially and used for study purposes only. Step 2 aimed to collecting basic information to characterize the participants via the Participant Characterization Form. Our major goal was profiling each developer, so we could better interpret our study results. We opted for asking short and simple questions in order to prevent participants from being tired or discouraged to participate in discussions right after filling out the form. More specifically, we collected data on the education level, years of experience with software development (academy and industry), the number of software projects they participated, and the level of knowledge about gamification and game design elements (see Table 16). Due to the geographic distribution of our participants, we used an online environment to promote discussions on the negative effects of game design elements. Figure 7 illustrates the virtual template that we designed using the MURAL online tool[2]. In practice, by using this tool, we were able to build an interactive mural to facilitate the conduction of the focus group session. Our mural has eight well-defined sections. Sections A to G aimed at driving the discussion regarding the negative effects of game design elements. In order to facilitate discussions, we have semantically grouped the game design elements by section as follow: (A) Badges and Rewards; (B) Competitions, Challenges, and Goals; (C) Leaderboards and Rankings; (D) Points, XPs, and Virtual Currencies; Feedback and Achievements; (E) Avatars; and (F) Quizzes. Finally, Section G aimed at driving the discussion and capturing the level of agreement on the usefulness, ease to use, and intention to use the information on potential negative effects of game design elements. Figure 8 illustrates the template that we have defined for each aforementioned section. A section is composed of four parts (1, 2, 3, and 4). Part 1 contains a short description of the involved game design elements and the identified negative effects based on the literature. Part 2 is designed for capturing votes on the awareness degree concern the negative effects based on a four-point scale: completely unaware, mostly unaware, mostly aware, and completely aware. Finally, parts 3 and 4 were designed for participants to add notes on the Pros and Cons of using the game design elements, respectively. Phase 2: Discussion by game design elements – This phase consists in collecting data regarding the developer’s perception of the negative effects identified in the literature. As aforementioned, we have divide the game design elements in groups to facilitate the discussions and used a Mural discussion canvas. Thus, each group of game design elements is discussed in isolation. We defined three steps as follows. Step 1 aimed at introducing each group of game design elements, and the negative effects. For this purpose, the moderator of the session read this information out loud (part 1 of Figure 8). Next, in Step 2, we asked each participant to assign one vote to the awareness degree of the group of game design elements according to the four-point scale depicted in part 2 of Figure 8. Each participant voted individually, without knowing the votes of his colleagues. At the end, the moderator showed the number of votes per awareness agree. Finally, in Step 3, we asked the participants to discuss and elicit Pros and Cons of using the game design elements. In this step, each comment should be documented as a note in the appropriate part: part 3 for positive comments and part 4 for negative ones, as shown in Figure 8. The note was just a brief summary of a Pro or a Con, typically taken within seconds, and we constantly asked participants to share knowledge and experiences surrounding the use of each game design element, to enrich the discussions and understandings. Additionally, whenever the moderator felt that a note is poorly written, he asked the participants to provide further considerations on the note. Phase 3: Discussion about the perception of the mapped negative effects – After discussing all groups of game design elements, the focus group session ended with a final discussion about the perceptions regarding the mapped negative effects. This phase has two steps described as follows. In Step 1, based on the main constructs of the Technology Acceptance Model (TAM) [113], we asked each participant to assign one vote to their agreement with each of the following statements (as illustrated in Section G of Figure 7): (1) I find the information on potential negative effects of game design elements useful to support game design element adoption decisions; (2) I find the information on potential negative effects of game design element easy to use to support game design element adoption decisions; and (3) I intend to use the information on potential negative effects of game design element to support game design element adoption decisions. We have used the five-point scale depicted in Figure 7 (G). Finally, Step 2 aimed at collecting data about the participant’s experience with the focus group session. Thus, by the end of the focus group session, we asked participants to fill out a Follow-up Form. We aimed at assuring that each developer felt confident and comfortable to discuss the negative effect of game design elements. We emphasize that the focus group session was conducted online via a Zoom Meeting. Additionally, we kept video and audio records of the session to support the data analysis. We often accessed the video and audio records for understanding what developers meant with each note. The focus group session was conducted in January 24, 2022 lasting one and a half hours. This paper is available on arxiv under CC BY 4.0 DEED license. [2] https://www.mural.co/ Authors: (1) Clauvin Almeida, Pontifical Catholic University of Rio de Janeiro (PUC-Rio), Rio de Janeiro, Brazil; (2) Marcos Kalinowski, Pontifical Catholic University of Rio de Janeiro (PUC-Rio), Rio de Janeiro, Brazil; (3) Anderson Uchoa, Federal University of Ceara (UFC), Itapaje, Brazil; (4) Bruno Feijo, Pontifical Catholic University of Rio de Janeiro (PUC-Rio), Rio de Janeiro, Brazil. Authors: Authors: (1) Clauvin Almeida, Pontifical Catholic University of Rio de Janeiro (PUC-Rio), Rio de Janeiro, Brazil; (2) Marcos Kalinowski, Pontifical Catholic University of Rio de Janeiro (PUC-Rio), Rio de Janeiro, Brazil; (3) Anderson Uchoa, Federal University of Ceara (UFC), Itapaje, Brazil; (4) Bruno Feijo, Pontifical Catholic University of Rio de Janeiro (PUC-Rio), Rio de Janeiro, Brazil. Table of Links Abstract and 1 Introduction Abstract and 1 Introduction 2. Background and Related Work and 2.1. Gamification 2. Background and Related Work and 2.1. Gamification 2.2. Game Design Elements and 2.3. Gamification Effects 2.2. Game Design Elements and 2.3. Gamification Effects 2.4. Related Work on Gamification Negative Effects 2.4. Related Work on Gamification Negative Effects 3. Systematic Mapping and 3.1. The Research Questions 3. Systematic Mapping and 3.1. The Research Questions 3.2. Search Strategy and 3.3. Inclusion and Exclusion Criteria 3.2. Search Strategy and 3.3. Inclusion and Exclusion Criteria 3.4. Applying the Search Strategy 3.4. Applying the Search Strategy 3.5. Data Extraction 3.5. Data Extraction 4. Systematic Mapping Results 4. Systematic Mapping Results 5. Focus Group: Developer Perception on the Negative Effects of Game Design Elements 5. Focus Group: Developer Perception on the Negative Effects of Game Design Elements 5.1. Context and Participant Characterization 5.1. Context and Participant Characterization 5.2. Focus Group Design 5.2. Focus Group Design 5.3. The Developers’ Perception on The Negative Effects 5.3. The Developers’ Perception on The Negative Effects 5.4. On the Perceived Usefulness, Ease of use and Intent of Adoption of Mapped Negative Effects 5.4. On the Perceived Usefulness, Ease of use and Intent of Adoption of Mapped Negative Effects 5.5. Participant Feedback 5.5. Participant Feedback 6. Limitations 6. Limitations 7. Concluding Remarks 7. Concluding Remarks 7.1. Future Research Directions 7.1. Future Research Directions Acknowledgements and References Acknowledgements and References 5.2. Focus Group Design We carefully designed and performed our focus group by following the guideline proposed by Kontio et al. [107]. Figure 6 depicts the steps adopted throughout the focus group. We organized these steps in three major phases: (1) Preparation for the focus group session; (2) Discussion by group of game design elements; and (3) Discussion on the perception of the mapped negative effects. We describe each phase and step hereafter. Phase 1: Preparation for the focus group session – This phase consists of the collection of preliminary resources for supporting the execution of the focus group session. For this purpose, we follow two steps. Step 1 consisted of recruiting developers with experience in gamification to engage in discussions. As mentioned in Section 5.1, we contacted developers of the VazaZika development team for participating in our study. We obtained the acceptance of four developers via Consent Form in which we explain our research goals, information about the waiver statements, and that the information provided by each participant will be treated confidentially and used for study purposes only. Step 2 aimed to collecting basic information to characterize the participants via the Participant Characterization Form. Our major goal was profiling each developer, so we could better interpret our study results. We opted for asking short and simple questions in order to prevent participants from being tired or discouraged to participate in discussions right after filling out the form. More specifically, we collected data on the education level, years of experience with software development (academy and industry), the number of software projects they participated, and the level of knowledge about gamification and game design elements (see Table 16). Phase 1: Preparation for the focus group session Step 1 Step 2 Due to the geographic distribution of our participants, we used an online environment to promote discussions on the negative effects of game design elements. Figure 7 illustrates the virtual template that we designed using the MURAL online tool[2]. In practice, by using this tool, we were able to build an interactive mural to facilitate the conduction of the focus group session. Our mural has eight well-defined sections. Sections A to G aimed at driving the discussion regarding the negative effects of game design elements. In order to facilitate discussions, we have semantically grouped the game design elements by section as follow: (A) Badges and Rewards; (B) Competitions, Challenges, and Goals; (C) Leaderboards and Rankings; (D) Points, XPs, and Virtual Currencies; Feedback and Achievements; (E) Avatars; and (F) Quizzes. Finally, Section G aimed at driving the discussion and capturing the level of agreement on the usefulness, ease to use, and intention to use the information on potential negative effects of game design elements. Figure 8 illustrates the template that we have defined for each aforementioned section. A section is composed of four parts (1, 2, 3, and 4). Part 1 contains a short description of the involved game design elements and the identified negative effects based on the literature. Part 2 is designed for capturing votes on the awareness degree concern the negative effects based on a four-point scale: completely unaware, mostly unaware, mostly aware, and completely aware. Finally, parts 3 and 4 were designed for participants to add notes on the Pros and Cons of using the game design elements, respectively. Phase 2: Discussion by game design elements – This phase consists in collecting data regarding the developer’s perception of the negative effects identified in the literature. As aforementioned, we have divide the game design elements in groups to facilitate the discussions and used a Mural discussion canvas. Thus, each group of game design elements is discussed in isolation. We Phase 2: Discussion by game design elements defined three steps as follows. Step 1 aimed at introducing each group of game design elements, and the negative effects. For this purpose, the moderator of the session read this information out loud (part 1 of Figure 8). Next, in Step 2 , we asked each participant to assign one vote to the awareness degree of the group of game design elements according to the four-point scale depicted in part 2 of Figure 8. Each participant voted individually, without knowing the votes of his colleagues. At the end, the moderator showed the number of votes per awareness agree. Finally, in Step 3 , we asked the participants to discuss and elicit Pros and Cons of using the game design elements. In this step, each comment should be documented as a note in the appropriate part: part 3 for positive comments and part 4 for negative ones, as shown in Figure 8. The note was just a brief summary of a Pro or a Con, typically taken within seconds, and we constantly asked participants to share knowledge and experiences surrounding the use of each game design element, to enrich the discussions and understandings. Additionally, whenever the moderator felt that a note is poorly written, he asked the participants to provide further considerations on the note. Step 1 Step 2 Step 3 Phase 3: Discussion about the perception of the mapped negative effects – After discussing all groups of game design elements, the focus group session ended with a final discussion about the perceptions regarding the mapped negative effects. This phase has two steps described as follows. In Step 1 , based on the main constructs of the Technology Acceptance Model (TAM) [113], we asked each participant to assign one vote to their agreement with each of the following statements (as illustrated in Section G of Figure 7): (1) I find the information on potential negative effects of game design elements useful to support game design element adoption decisions; (2) I find the information on potential negative effects of game design element easy to use to support game design element adoption decisions; and (3) I intend to use the information on potential negative effects of game design element to support game design element adoption decisions. We have used the five-point scale depicted in Figure 7 (G). Finally, Step 2 aimed at collecting data about the participant’s experience with the focus group session. Thus, by the end of the focus group session, we asked participants to fill out a Follow-up Form. We aimed at assuring that each developer felt confident and comfortable to discuss the negative effect of game design elements. Phase 3: Discussion about the perception of the mapped negative effects Step 1 Step 2 We emphasize that the focus group session was conducted online via a Zoom Meeting. Additionally, we kept video and audio records of the session to support the data analysis. We often accessed the video and audio records for understanding what developers meant with each note. The focus group session was conducted in January 24, 2022 lasting one and a half hours. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv [2] https://www.mural.co/

Focus Group Insights on Game Design Elements

What to Watch for: 5 Must-Have Elements in Crypto Whitepapers

Kunas uñjañasa: 5 Elementos Must-Have en Cripto Janq’u qillqatanaka

За какво да внимавате: 5 задължителни елемента в крипто белите книги

Na šta treba obratiti pažnju: 5 obaveznih elemenata u kripto bijelim papirima

Worauf Sie achten sollten: 5 unverzichtbare Elemente in Krypto-Whitepapers

Qué tener en cuenta: 5 elementos imprescindibles en los documentos técnicos sobre criptomonedas

Zer ikusi: 5 elementu ezinbestekoak Crypto Whitepapers

O que hai que ter en conta: 5 elementos imprescindibles nos documentos brancos de cripto

למה לצפות: 5 אלמנטים חובה במסמכי קריפטו

注目すべき点: 暗号通貨のホワイトペーパーに必須の 5 つの要素

Kam jāpievērš uzmanība: 5 obligātie elementi kriptogrāfijās

สิ่งที่ต้องจับตามอง: 5 องค์ประกอบที่ต้องมีใน Crypto Whitepapers

Nämä tomaşa etmeli: Kripto sahypalarynda 5 element bolmaly

If you’ve been writing Go code for a while, you’ve probably come across range loops. They’re elegant, concise, and incredibly handy for iterating over slices, maps, and channels. But did you know that their behavior can sometimes be counterintuitive, leading to subtle bugs in your code? In this article, I’ll break down the mechanics of range loops, explain why these quirks occur, and share actionable tips to avoid common pitfalls. By the end, you’ll have a deeper understanding of Go and be better equipped to write reliable, bug-free code. 🚀 What Makes Range Loops Tricky? At first glance, range loops in Go appear straightforward. Here’s an example you’ve likely seen: codenumbers := []int{1, 2, 3, 4, 5}  
for index, value := range numbers {  
    fmt.Printf("Index: %d, Value: %d\n", index, value)  
} This prints the index and value for each element in the slice. Simple, right? But here’s where things get interesting (and potentially frustrating). The Underlying Mechanics of Range When you use range, Go creates a copy of the value you’re iterating over. For slices, this means you’re not directly accessing the elements but working with their copies. This subtle detail can lead to unexpected behavior. Take this example: codewords := []string{"Go", "is", "awesome"}  
wordPointers := []*string{}  

for _, word := range words {  
    wordPointers = append(wordPointers, &word)  
}  

for _, pointer := range wordPointers {  
    fmt.Println(*pointer)  
} You might expect this to print: Go  
is  
awesome But instead, you’ll see: awesome  
awesome  
awesome Why? Because word is a single variable reused in every iteration. The loop appends the same variable’s address each time, and by the end of the loop, word holds the value of the last element. Avoiding Common Pitfalls Here are some tips to keep your range loops bug-free: Understand Copying Behavior:If you’re modifying elements, remember thatrange loops work with copies for slices and arrays. Use index-based access if you need to modify the original elements.
for i := range numbers {  
    numbers[i] *= 2  
}  




Be Cautious with Pointers:If you need to capture references to elements, use the index instead of the loop variable.
for i := range words {  
    wordPointers = append(wordPointers, &words[i])  
}  




Debug Complex Loops:Usefmt.Printf to inspect variables and their memory addresses. This helps identify if you’re unintentionally working with shared references. Why This Matters Understanding these quirks isn’t just about avoiding bugs—it’s about mastering Go. As you tackle more complex projects, these small details can have significant impacts on performance, correctness, and maintainability. This article is part of a series I’m writing to explore common mistakes in Go programming. The first topic, range loops, is something many developers encounter but don’t fully understand until they’ve run into a bug. Final Thoughts Range loops are one of Go’s most powerful tools, but like any tool, they come with nuances. By understanding how they evaluate and iterate over elements, you can write cleaner, more reliable code. If you’ve ever been bitten by a range loop bug—or have tips of your own—I’d love to hear from you! Let’s share knowledge and grow as a community. 🔗 Read the full article on my LinkedIn For more insights like this, follow my journey in exploring the intricacies of Go programming. 🚀 If you’ve been writing Go code for a while, you’ve probably come across range loops. They’re elegant, concise, and incredibly handy for iterating over slices, maps, and channels. But did you know that their behavior can sometimes be counterintuitive, leading to subtle bugs in your code? range In this article, I’ll break down the mechanics of range loops, explain why these quirks occur, and share actionable tips to avoid common pitfalls. By the end, you’ll have a deeper understanding of Go and be better equipped to write reliable, bug-free code. 🚀 range What Makes Range Loops Tricky? What Makes Range At first glance, range loops in Go appear straightforward. Here’s an example you’ve likely seen: range codenumbers := []int{1, 2, 3, 4, 5}  
for index, value := range numbers {  
    fmt.Printf("Index: %d, Value: %d\n", index, value)  
} codenumbers := []int{1, 2, 3, 4, 5}  
for index, value := range numbers {  
    fmt.Printf("Index: %d, Value: %d\n", index, value)  
} This prints the index and value for each element in the slice. Simple, right? But here’s where things get interesting (and potentially frustrating). The Underlying Mechanics of Range The Underlying Mechanics of Range When you use range , Go creates a copy of the value you’re iterating over. For slices, this means you’re not directly accessing the elements but working with their copies. This subtle detail can lead to unexpected behavior. range Take this example: codewords := []string{"Go", "is", "awesome"}  
wordPointers := []*string{}  

for _, word := range words {  
    wordPointers = append(wordPointers, &word)  
}  

for _, pointer := range wordPointers {  
    fmt.Println(*pointer)  
} codewords := []string{"Go", "is", "awesome"}  
wordPointers := []*string{}  

for _, word := range words {  
    wordPointers = append(wordPointers, &word)  
}  

for _, pointer := range wordPointers {  
    fmt.Println(*pointer)  
} You might expect this to print: Go  
is  
awesome Go  
is  
awesome But instead, you’ll see: awesome  
awesome  
awesome awesome  
awesome  
awesome Why? Because word is a single variable reused in every iteration. The loop appends the same variable’s address each time, and by the end of the loop, word holds the value of the last element. word word Avoiding Common Pitfalls Avoiding Common Pitfalls Here are some tips to keep your range loops bug-free: range Understand Copying Behavior:If you’re modifying elements, remember thatrange loops work with copies for slices and arrays. Use index-based access if you need to modify the original elements.
for i := range numbers {  
    numbers[i] *= 2  
} Be Cautious with Pointers:If you need to capture references to elements, use the index instead of the loop variable.
for i := range words {  
    wordPointers = append(wordPointers, &words[i])  
} Debug Complex Loops:Usefmt.Printf to inspect variables and their memory addresses. This helps identify if you’re unintentionally working with shared references. Understand Copying Behavior:If you’re modifying elements, remember thatrange loops work with copies for slices and arrays. Use index-based access if you need to modify the original elements. for i := range numbers {  
    numbers[i] *= 2  
} Understand Copying Behavior : If you’re modifying elements, remember that range loops work with copies for slices and arrays. Use index-based access if you need to modify the original elements. Understand Copying Behavior range for i := range numbers {  
    numbers[i] *= 2  
} for i := range numbers {  
    numbers[i] *= 2  
} Be Cautious with Pointers:If you need to capture references to elements, use the index instead of the loop variable. for i := range words {  
    wordPointers = append(wordPointers, &words[i])  
} Be Cautious with Pointers : If you need to capture references to elements, use the index instead of the loop variable. Be Cautious with Pointers for i := range words {  
    wordPointers = append(wordPointers, &words[i])  
} for i := range words {  
    wordPointers = append(wordPointers, &words[i])  
} Debug Complex Loops:Usefmt.Printf to inspect variables and their memory addresses. This helps identify if you’re unintentionally working with shared references. Debug Complex Loops : Use fmt.Printf to inspect variables and their memory addresses. This helps identify if you’re unintentionally working with shared references. Debug Complex Loops fmt.Printf Why This Matters Why This Matters Understanding these quirks isn’t just about avoiding bugs—it’s about mastering Go. As you tackle more complex projects, these small details can have significant impacts on performance, correctness, and maintainability. This article is part of a series I’m writing to explore common mistakes in Go programming. The first topic, range loops, is something many developers encounter but don’t fully understand until they’ve run into a bug. range Final Thoughts Final Thoughts Range loops are one of Go’s most powerful tools, but like any tool, they come with nuances. By understanding how they evaluate and iterate over elements, you can write cleaner, more reliable code. Range If you’ve ever been bitten by a range loop bug—or have tips of your own—I’d love to hear from you! Let’s share knowledge and grow as a community. range 🔗 Read the full article on my LinkedIn Read the full article on my LinkedIn For more insights like this, follow my journey in exploring the intricacies of Go programming. 🚀

Unlock the Secrets of Range Loops: How Element Evaluation Affects Your Go Code

Recently came an interesting task, changing custom SVG, to a Webflow project for the animation. I thought it was no big deal, opened a Figma, took the source code of the SVG, threw it in and .... didn't work 😔 Researching the problem, it turned out that the library that animates SVG works directly with rect elements inside the same SVG. Well again no problem I thought :), let's just rename all layers to Rect and we'll be happy. Renamed, I looked at the SVG source code and I don't see rect :( Then, I sat down much more comfortably in my chair and started researching more efficiently. It turned out that for SVG to understand the elements we want to animate as recr we need to draw them.... drum roll - through Frames. Started testing, and everything works. But now there is another problem: How to automate this process? We already have a lot of drawn illustrations, and we don't want to redo them. Well, since we are working in Frames, we have found a way out, need to create the plugin that will wrap all elements in frames. The source code of the Plugin: const selectedNodes = figma.currentPage.selection;

if (selectedNodes.length === 0) {
  figma.notify("Please select at least one layer.");
} else {
  selectedNodes.forEach(node => {
    const frame = figma.createFrame();
    frame.resize(node.width, node.height);
    frame.x = node.x;
    frame.y = node.y;
    frame.appendChild(node);
    node.x = 0;
    node.y = 0;
  });

  figma.notify("All selected layers are wrapped in frames!");
}

figma.closePlugin(); or download the project on GitHub :-) Result: 30 minutes of code and all animations work, work for the future is done. Conclusion: if you can't find interesting tasks, they will find you themselves. Automate everything :) Recently came an interesting task, changing custom SVG, to a Webflow project for the animation. I thought it was no big deal, opened a Figma, took the source code of the SVG, threw it in and .... didn't work 😔 didn't work didn't work Researching the problem, it turned out that the library that animates SVG works directly with rect elements inside the same SVG. Well again no problem I thought :), let's just rename all layers to Rect and we'll be happy. rect Renamed, I looked at the SVG source code and I don't see rect :( rect Then, I sat down much more comfortably in my chair and started researching more efficiently. It turned out that for SVG to understand the elements we want to animate as recr we need to draw them.... drum roll - through Frames. recr Started testing, and everything works. But now there is another problem: How to automate this process? How to automate this process? We already have a lot of drawn illustrations, and we don't want to redo them. Well, since we are working in Frames, we have found a way out, need to create the plugin that will wrap all elements in frames. plugin The source code of the Plugin: const selectedNodes = figma.currentPage.selection;

if (selectedNodes.length === 0) {
  figma.notify("Please select at least one layer.");
} else {
  selectedNodes.forEach(node => {
    const frame = figma.createFrame();
    frame.resize(node.width, node.height);
    frame.x = node.x;
    frame.y = node.y;
    frame.appendChild(node);
    node.x = 0;
    node.y = 0;
  });

  figma.notify("All selected layers are wrapped in frames!");
}

figma.closePlugin(); const selectedNodes = figma.currentPage.selection;

if (selectedNodes.length === 0) {
  figma.notify("Please select at least one layer.");
} else {
  selectedNodes.forEach(node => {
    const frame = figma.createFrame();
    frame.resize(node.width, node.height);
    frame.x = node.x;
    frame.y = node.y;
    frame.appendChild(node);
    node.x = 0;
    node.y = 0;
  });

  figma.notify("All selected layers are wrapped in frames!");
}

figma.closePlugin(); or download the project on GitHub :-) GitHub Result: 30 minutes of code and all animations work, work for the future is done. Conclusion: if you can't find interesting tasks, they will find you themselves. Automate everything :)

Tutorial: How to Turn Figma Files to SVG with Rect Elements

Падручнік: як ператварыць файлы Figma у SVG з элементамі Rect

Урок: Как да превърнете Figma файлове в SVG с Rect елементи

Tutorial: Cómo convertir archivos Figma a SVG con elementos Rect

آموزش: نحوه تبدیل فایل های Figma به SVG با عناصر Rect

Tutorial: Ki jan yo vire fichye Figma nan SVG ak eleman Rect

Tutorial: come trasformare i file Figma in SVG con elementi Rect

מדריך: כיצד להפוך קבצי Figma ל-SVG עם רכיבי Rect

チュートリアル: Figma ファイルを Rect 要素付きの SVG に変換する方法

Упатство: Како да ги претворите Figma-датотеките во SVG со Rect Elements

Samouczek: Jak przekształcić pliki Figma do formatu SVG za pomocą elementów Rect

Tutorial: Si t'i ktheni skedarët Figma në SVG me Elemente Rect

Qo'llanma: Figma fayllarini to'g'ri elementlar bilan SVGga qanday aylantirish mumkin

How to Convert Videos to HLS for Web & Mobile Streaming With AWS Elemental MediaConvert

Πώς να μετατρέψετε βίντεο σε HLS για ροή ιστού και κινητών με το AWS Elemental MediaConvert

Cómo convertir vídeos a HLS para transmisión web y móvil con AWS Elemental MediaConvert

Videoiden muuntaminen HLS:ksi verkko- ja mobiilisuoratoistoa varten AWS Elemental MediaConvertin avulla

AWS Elemental MediaConvert を使用してビデオを HLS に変換し、ウェブおよびモバイルストリーミングに配信する方法

Kā konvertēt videoklipus uz HLS straumēšanai tīmeklī un mobilajās ierīcēs, izmantojot AWS Elemental MediaConvert

AWS Elemental MediaConvert ашиглан вэб болон гар утасны урсгалд зориулсан видеог хэрхэн HLS болгон хөрвүүлэх вэ

Hoe u video's naar HLS kunt converteren voor web- en mobiele streaming met AWS Elemental MediaConvert

Maitiro ekushandura Vhidhiyo kuita HLS yeWebhu & Nhare Kutenderera NeAWS Elemental MediaConvert

AWS எலிமெண்டல் மீடியா கன்வெர்ட் மூலம் இணையம் மற்றும் மொபைல் ஸ்ட்ரீமிங்கிற்கான வீடியோக்களை HLS ஆக மாற்றுவது எப்படி

Paano Mag-convert ng Mga Video sa HLS para sa Web at Mobile Streaming Gamit ang AWS Elemental MediaConvert

AWS Elemental MediaConvert ile Web ve Mobil Yayın için Videoları HLS'ye Nasıl Dönüştürebilirsiniz

Як конвертувати відео в HLS для потокового передавання через Інтернет і мобільні пристрої за допомогою AWS Elemental MediaConvert

Identity Lifecycle Management (ILM), is a crucial component of enterprise Identity and Access Management (IAM) architecture, it also sometimes referred to as joiner-mover-leaver process. The goal of ILM is to minimize security risks by avoiding over-provisioning and under-provisioning of access rights. This is more important for companies that heavily depend on third party (3p) SaaS applications and allows personal devices (concept known as bring your own devices or BYOD) to access them. If provisioning access takes too long, the productivity of the employee is impacted, and if deprovisioning of access also takes too long, damage beyond repair can be done by the same employee knowingly or not. This article explains why Single Sign On (SSO) cannot solve all of it, and provides details about a companion, System for Cross-domain Identity Management (SCIM) to complete the picture. Identity Lifecycle Management To build a robust ILM system, various departments within the company work together, starting with Human Resources (HR). Onboarding of an employee starts with HR, then supported by the Information Security team until the employee's termination via a set of tools and procedures. Companies, irrespective of size, establish processes to hire, manage internal transfers and terminate employees. These vary from one to another based on size, from entirely manual and ticketing steps to automated workflows. At smaller to medium sized companies, processes involve direct interaction between teams, one informs another about a new hire, requests hardware and network credentials, and similarly notifies when an account should be removed upon termination. Larger companies with dedicated technology teams, ILM process is typically semi or fully automated. They are often supported by HR IT onboarding systems that create accounts, trigger notifications for hardware and credential creation, and support termination, access revocation through similar systems. Single Sign On We enforce Single Sign On (SSO), it will take care of automating access to applications, correct? Wrong. SSO is an important piece of the IAM ecosystem, but it alone does not automate access management. It is much evident during employee offboarding without a stronger ILM process to complement SSO. Many that work in technology, particularly those that are not familiar with all the ins and outs of IAM processes, assume that SSO automatically handles access revocation when an employee leaves. However, the effectiveness of SSO in this context depends on several factors. Companies with strict SSO policies prohibiting access to applications from non-employer-managed devices and can immediately disable access upon employment termination may have better control. If the company allows BYOD, revoking access becomes more challenging without an automated mechanism. In cases where SaaS applications create their own user sessions and do not frequently verify the state with an SSO provider (through OAuth refresh tokens for example), will continue to honor the session. Some third-party SaaS applications also offer SSO bypass ability, allowing users to log in with application-specific credentials, circumventing SSO-based controls. Welcome to SCIM For comprehensive access management, especially in environments supporting BYOD model, automated access revocation processes are critical. SCIM, or System for Cross-domain Identity Management, is a standard designed to manage user identity information across multiple domains and applications, cloud or otherwise. SCIM's design and development are guided by several RFCs, including 7643, 7644, and 7642. SCIM 2.0, the latest version of the protocol supports more attributes, operations and strict security requirements such as mandatory TLS 1.2. SCIM automates the process of approving and revoking user accounts in applications that support the protocol no matter where they are deployed. By using standardized protocols like REST and data formats such as JSON, SCIM enables seamless and secure communication of identity data between both identity (IdP) and service providers (SP). This reduces the burden on IT departments, minimizes human errors, and enhances security by ensuring that access is promptly updated or revoked as needed. Getting into technical details, SCIM supports two important endpoints: /users and /groups. Users endpoint is used for managing users and attributes such as email via various operations (create, patch, delete, etc.,). Groups allow membership updates which can be used for authorization policies on the SP. Customers can create integration to these endpoints with their entitlement management systems (e.g., an IdP managed group membership) and sync the changes automatically. This not only helps with deprovisioning of users when they leave but also helps with internal role changes. Most of the Identity as a Service (IDaaS) solutions available on the market support SSO and SCIM as part of the same application setup process making it easy to implement. Conclusion Per one of the well-known IDaaS with largest collection of SaaS integrations that I am aware of, less than 25% of the apps that support SSO via SAML and OIDC also support SCIM. I would like to conclude this article with requests to SPs and enterprise IAM teams to increase SCIM adoption. SPs should go beyond SSO and must consider supporting SCIM as part of their product (free of charge!) for their customers. IAM teams must enable SCIM for existing SPs if supported and push the remaining to support. Opinions expressed in this article are solely the Author's own and do not express the views or opinions of the Author's employer. Identity Lifecycle Management (ILM), is a crucial component of enterprise Identity and Access Management (IAM) architecture, it also sometimes referred to as joiner-mover-leaver process. The goal of ILM is to minimize security risks by avoiding over-provisioning and under-provisioning of access rights. This is more important for companies that heavily depend on third party (3p) SaaS applications and allows personal devices (concept known as bring your own devices or BYOD) to access them. If provisioning access takes too long, the productivity of the employee is impacted, and if deprovisioning of access also takes too long, damage beyond repair can be done by the same employee knowingly or not. This article explains why Single Sign On (SSO) cannot solve all of it, and provides details about a companion, System for Cross-domain Identity Management (SCIM) to complete the picture. Identity Lifecycle Management To build a robust ILM system, various departments within the company work together, starting with Human Resources (HR). Onboarding of an employee starts with HR, then supported by the Information Security team until the employee's termination via a set of tools and procedures. Companies, irrespective of size, establish processes to hire, manage internal transfers and terminate employees. These vary from one to another based on size, from entirely manual and ticketing steps to automated workflows. At smaller to medium sized companies, processes involve direct interaction between teams, one informs another about a new hire, requests hardware and network credentials, and similarly notifies when an account should be removed upon termination. Larger companies with dedicated technology teams, ILM process is typically semi or fully automated. They are often supported by HR IT onboarding systems that create accounts, trigger notifications for hardware and credential creation, and support termination, access revocation through similar systems. Single Sign On We enforce Single Sign On (SSO), it will take care of automating access to applications, correct? Wrong. SSO is an important piece of the IAM ecosystem, but it alone does not automate access management. It is much evident during employee offboarding without a stronger ILM process to complement SSO. Many that work in technology, particularly those that are not familiar with all the ins and outs of IAM processes, assume that SSO automatically handles access revocation when an employee leaves. However, the effectiveness of SSO in this context depends on several factors. Companies with strict SSO policies prohibiting access to applications from non-employer-managed devices and can immediately disable access upon employment termination may have better control. If the company allows BYOD, revoking access becomes more challenging without an automated mechanism. In cases where SaaS applications create their own user sessions and do not frequently verify the state with an SSO provider (through OAuth refresh tokens for example), will continue to honor the session. Some third-party SaaS applications also offer SSO bypass ability, allowing users to log in with application-specific credentials, circumventing SSO-based controls. Welcome to SCIM For comprehensive access management, especially in environments supporting BYOD model, automated access revocation processes are critical. SCIM, or System for Cross-domain Identity Management, is a standard designed to manage user identity information across multiple domains and applications, cloud or otherwise. SCIM's design and development are guided by several RFCs, including 7643, 7644, and 7642. SCIM 2.0, the latest version of the protocol supports more attributes, operations and strict security requirements such as mandatory TLS 1.2. SCIM automates the process of approving and revoking user accounts in applications that support the protocol no matter where they are deployed. By using standardized protocols like REST and data formats such as JSON, SCIM enables seamless and secure communication of identity data between both identity (IdP) and service providers (SP). This reduces the burden on IT departments, minimizes human errors, and enhances security by ensuring that access is promptly updated or revoked as needed. Getting into technical details, SCIM supports two important endpoints: /users and /groups. Users endpoint is used for managing users and attributes such as email via various operations (create, patch, delete, etc.,). Groups allow membership updates which can be used for authorization policies on the SP. Customers can create integration to these endpoints with their entitlement management systems (e.g., an IdP managed group membership) and sync the changes automatically. This not only helps with deprovisioning of users when they leave but also helps with internal role changes. Most of the Identity as a Service (IDaaS) solutions available on the market support SSO and SCIM as part of the same application setup process making it easy to implement. Conclusion Per one of the well-known IDaaS with largest collection of SaaS integrations that I am aware of, less than 25% of the apps that support SSO via SAML and OIDC also support SCIM. I would like to conclude this article with requests to SPs and enterprise IAM teams to increase SCIM adoption. SPs should go beyond SSO and must consider supporting SCIM as part of their product (free of charge!) for their customers. IAM teams must enable SCIM for existing SPs if supported and push the remaining to support. Opinions expressed in this article are solely the Author's own and do not express the views or opinions of the Author's employer. Opinions expressed in this article are solely the Author's own and do not express the views or opinions of the Author's employer.

SCIM: A Critical Yet Underappreciated Element in Enterprise IAM

Stories, News & Mentions about ELEMENT

Categories

Trending Topics

Stories, News & Mentions about ELEMENT

Element’s Stories on HackerNoon

Element's News & Mentions

Categories

Trending Topics