diff --git a/rfcs/0001-animation-slide-side.md b/rfcs/0001-animation-slide-side.md
index a5945cc..c7f0e89 100644
--- a/rfcs/0001-animation-slide-side.md
+++ b/rfcs/0001-animation-slide-side.md
@@ -6,49 +6,149 @@ author: Ciflire
 
 # Summary
 
-This RFC aims to agree on a rule for forced side option of the slide animation style
+This RFC aims to agree on a rule for forced side option of the slide animation
+style
 
 # Motivation
 
-The way the animation `slide` is used feels inconsistent in two ways at the moment i'm writing this:
-- First, it describes a side that can be the side by which the animation starts as well as its end. For example the keyword `bottom` used for animation `windowsIn` will move the window **from** the bottom to the desired position and for the animation `windowsOut` the window will be slided to the bottom of the screen
-- Secondly, following that logic, the keyword `bottom` would be used to make the window pop from the bottom and close sliding to the bottom. The same keyword is then used for two different visual results.
-This RFC will allow to write the documentation as clear as possible without having to detail each case, or by try and fail by the user
+The way the animation `slide` is used feels inconsistent in two ways at the
+moment i'm writing this:
+
+- First, it describes a side that can be the side by which the animation starts
+  as well as its end. For example the keyword `bottom` used for animation
+  `windowsIn` will move the window **from** the bottom to the desired position
+  and for the animation `windowsOut` the window will be slided to the bottom of
+  the screen
+- Secondly, following that logic, the keyword `bottom` would be used to make the
+  window pop from the bottom and close sliding to the bottom. The same keyword
+  is then used for two different visual results.
+- The use of the term "slide" makes the user consider the movement and not the
+  side This RFC will allow to write the documentation as clear as possible
+  without having to detail each case, or by try and fail by the user
 
 # Detailed design
 
-The new design for the forced side
+The design at the moment is that the orientation of the animation depends on
+wether the window is closed or not.
+
+```cpp
+// src/managers/AnimationManager.cpp
+void CAnimationManager::animationSlide(PHLWINDOW pWindow, std::string force, bool close) {
+    pWindow->m_vRealSize.warp(false); // size we preserve in slide
+
+    const auto GOALPOS  = pWindow->m_vRealPosition.goal();
+    const auto GOALSIZE = pWindow->m_vRealSize.goal();
+
+    const auto PMONITOR = g_pCompositor->getMonitorFromID(pWindow->m_iMonitorID);
+
+    if (!PMONITOR)
+        return; // unsafe state most likely
+
+    Vector2D posOffset;
+
+    if (force != "") {
+        if (force == "bottom")
+            posOffset = Vector2D(GOALPOS.x, PMONITOR->vecPosition.y + PMONITOR->vecSize.y);
+        else if (force == "left")
+            posOffset = GOALPOS - Vector2D(GOALSIZE.x, 0.0);
+        else if (force == "right")
+            posOffset = GOALPOS + Vector2D(GOALSIZE.x, 0.0);
+        else
+            posOffset = Vector2D(GOALPOS.x, PMONITOR->vecPosition.y - GOALSIZE.y);
+
+        if (!close)
+            pWindow->m_vRealPosition.setValue(posOffset);
+        else
+            pWindow->m_vRealPosition = posOffset;
+
+        return;
+    }
+
+    const auto MIDPOINT = GOALPOS + GOALSIZE / 2.f;
+
+    // check sides it touches
+    const bool DISPLAYLEFT   = STICKS(pWindow->m_vPosition.x, PMONITOR->vecPosition.x + PMONITOR->vecReservedTopLeft.x);
+    const bool DISPLAYRIGHT  = STICKS(pWindow->m_vPosition.x + pWindow->m_vSize.x, PMONITOR->vecPosition.x + PMONITOR->vecSize.x - PMONITOR->vecReservedBottomRight.x);
+    const bool DISPLAYTOP    = STICKS(pWindow->m_vPosition.y, PMONITOR->vecPosition.y + PMONITOR->vecReservedTopLeft.y);
+    const bool DISPLAYBOTTOM = STICKS(pWindow->m_vPosition.y + pWindow->m_vSize.y, PMONITOR->vecPosition.y + PMONITOR->vecSize.y - PMONITOR->vecReservedBottomRight.y);
+
+    if (DISPLAYBOTTOM && DISPLAYTOP) {
+        if (DISPLAYLEFT && DISPLAYRIGHT) {
+            posOffset = GOALPOS + Vector2D(0.0, GOALSIZE.y);
+        } else if (DISPLAYLEFT) {
+            posOffset = GOALPOS - Vector2D(GOALSIZE.x, 0.0);
+        } else {
+            posOffset = GOALPOS + Vector2D(GOALSIZE.x, 0.0);
+        }
+    } else if (DISPLAYTOP) {
+        posOffset = GOALPOS - Vector2D(0.0, GOALSIZE.y);
+    } else if (DISPLAYBOTTOM) {
+        posOffset = GOALPOS + Vector2D(0.0, GOALSIZE.y);
+    } else {
+        if (MIDPOINT.y > PMONITOR->vecPosition.y + PMONITOR->vecSize.y / 2.f)
+            posOffset = Vector2D(GOALPOS.x, PMONITOR->vecPosition.y + PMONITOR->vecSize.y);
+        else
+            posOffset = Vector2D(GOALPOS.x, PMONITOR->vecPosition.y - GOALSIZE.y);
+    }
+
+    if (!close)
+        pWindow->m_vRealPosition.setValue(posOffset);
+    else
+        pWindow->m_vRealPosition = posOffset;
+}
+```
+
+I'm giving my example that i tested and apologize for the bad quality. I only
+changed the `if` statements where `force` argument is not empty.
+
+```cpp
+if (force != "") {
+    if (force == "bottom" && !close)
+        posOffset = Vector2D(GOALPOS.x, PMONITOR->vecPosition.y - PMONITOR->vecSize.y);
+    else if (force == "bottom")
+        posOffset = Vector2D(GOALPOS.x, PMONITOR->vecPosition.y + PMONITOR->vecSize.y);
+    else if (force == "left" && !close)
+        posOffset = GOALPOS + Vector2D(GOALSIZE.x, 0.0);
+    else if (force == "left")
+        posOffset = GOALPOS - Vector2D(GOALSIZE.x, 0.0);
+    else if (force == "right" && !close)
+        posOffset = GOALPOS - Vector2D(GOALSIZE.x, 0.0);
+    else if (force == "right")
+        posOffset = GOALPOS + Vector2D(GOALSIZE.x, 0.0);
+    else if (force == "top" && !close)
+        posOffset = Vector2D(GOALPOS.x, PMONITOR->vecPosition.y + PMONITOR->vecSize.y);
+    else if (force == "top")
+        posOffset = Vector2D(GOALPOS.x, PMONITOR->vecPosition.y - PMONITOR->vecSize.y);
+```
+
+I guess it could be refactored but i do not have the experience yet to do it
+(intoducing a close bit for example). The slide direction does not depend on
+whether the window is opened or closed. Meaning `slide top` will allways slide
+the window to the top.
 
 # Examples and Interactions
 
-The previous configuration would be rewritten into
-
-```
-animation=windowsIn, 1,2,windowIn, slide top
-animation=windowsOut,1,2,windowOut, slide bottom
-```
-
-Where `top` and `bottom` give the direction of the window when going in or out.
-
 # Drawbacks
 
-People would have to change this in their entire config, could also be
-counterintuitive to other people just as the way it is designed today is
-counterintuitive to me Having to change the actual implementation
+- Users will have to modify their configuration based on that change
+- Could feel counterintuitive to users (as much as the actual behaviour is to
+  me)
 
 # Alternatives
 
-Keeping the way it is
+- Keeping the way it is
 
 # Prior art
 
-This is already impleted
+[This issue](https://github.com/hyprwm/Hyprland/issues/6826) mentions the way
+animation work. I will emphasize the end of the description section "using
+`slide top` (it then slides down)". The user has to describe the exact visual
+result of that animation. I will allow myself to infer that the need to give
+this information means that it doesn't feel intuitive to the user. This is also
+a pretty recent change as it was implemented and merged the 15th of june. Before
+that the option existed but was not parsed (ref:
+[6512](https://github.com/hyprwm/Hyprland/issues/6512))
 
 # Unresolved questions
 
-Still no community feedback so I use this dedicated space to have some
-
 # Future work
-
-Feel free to criticize it, sorry for my English as well i'm not native, also
-first time doing an RFC