[Feature Request] : [User Experience] : cannot enlarge the panel of hamburger menu

[rohithmn3]

Hi Team,

on the concourse UI dashboard, on the left top corner, we have the hamburger menu to view all the teams and we could expand each team to view the pipelines in them. But the problem is "the opened hamburger menu is of fixed size, and if our pipeline name is a bit long we have to hover the mouse on the pipeline name to view the full name of the pipeline". This is not good user experience. So could you please make that left panel is adjustable so that one can see the full pipeline names.

Please find the attachment where I cannot see the full name of my pipelines.

Below screenshot points that we cannot enlarge the panel.

Regards,
Rohith

[aoldershaw]

This could pretty trivially be implemented by adding the following CSS to the #side-bar element:

resize: horizontal;
overflow-x: hidden;

Additionally, we'd need to handle the sidebar's onresize events to re-trigger GetViewportOf Dashboard in order to recompute the layout of pipeline cards (much like we do when the window is resized:

concourse/web/elm/src/Dashboard/Dashboard.elm

Lines 396 to 397 in 77ab1d1

	WindowResized _ _ ->
	( model, effects ++ [ GetViewportOf Dashboard AlwaysShow ] )

)

The downside to this approach is that using CSS' resize: horizontal only gives a small resize handle in the bottom right corner, rather than the more intuitive approach of having the entire right side be draggable. See the screenshot below to see what the resize handle looks like in Chrome:

Additionally, resize: horizontal doesn't work in IE.

Another approach is to port something like this over to Elm (https://stackoverflow.com/a/53220241/9994448). Slightly more work, but would give us more control over the UX.

[aoldershaw]

Hm, looks like I was wrong about onresize events - it's only supported for window, rather than general divs. We'll need another way of detecting when we are resizing the sidebar (could be a ResizeObserver through ports, but support is pretty bad: https://caniuse.com/#feat=resizeobserver

[aoldershaw]

Actually, looking a bit closer, it seems like the CSS resize property also has pretty bad support: https://caniuse.com/#feat=css-resize (a lot of this is mobile, which won't even have a sidebar in most cases, but it's also unsupported by IE)

We may have to have a resize handle on the side edge

[rohithmn3]

@aoldershaw ,
So you will be implementing a resize handle on the side-bar as shown by the @matthewpereira in below comments right..!
So, when can we expect this feature on the PROD concourse? :)

[aoldershaw]

@rohithmn3 currently, this isn't prioritized, so I'm not sure when we'll be able to get to it. If I get the chance, I'll be happy to work on it, but no guarantees on when that will be.

With that said, I'd be happy if you (or anyone else who comes across this thread) is interested in implementing it! The Elm codebase can be a bit daunting at first if you've never used Elm, but it's really not that bad! I'll try to give a brief summary of roughly what needs to change to implement this feature:

Rendering the Sidebar

Unfortunately, the approach I initially mentioned that just uses CSS resize: horizontal to add a handle won't really work for our case - there isn't a well-supported browser way to listen for these resize events. So, it turns out that having a resize handle along the side of the pipeline bar will likely be easier to implement (and result in a better UX).

Most of the files of interest reside in web/elm/src/SideBar.

SideBar.elm contains the Model, view and update functions for the sidebar. Model is the current state of the sidebar. view is responsible for rendering the sidebar (as well as adding event handlers to the DOM elements), and update is responsible for handling the events generated by those event handlers.

On our Model, we'll want to add a width field so that we can track and update it's size.

Currently, we our view looks like:

view model currentPipeline =
    ...
        Html.div
            (id "side-bar" :: Styles.sideBar)
            ...

(by the way, the way we create divs in Elm is Html.div [list of attributes] [list of child elements])

We'll want to wrap the sidebar element in a parent div so we can have a handle element:

view model currentPipeline =
    ...
        Html.div
            []
            [ Html.div (id "side-bar" :: Styles.sideBar model.width) ...
            , Html.div (id "side-bar-handle" :: Styles.sideBarHandle) []
            ]
            ...

This brings us to Styles.elm, which we use to group the CSS styles. Each element with custom styles has a function in the Styles module (e.g. Styles.sideBar). Note the addition of model.width to the Styles.sideBar function call - this is so we can change our styling depending on the width (in particular, we'll just want to set the width property in CSS to that model.width.

sideBar : Float -> List (Html.Attribute msg)
sideBar width =
    [ ...
    , style "width" <| String.fromFloat width ++ "px"
    ...
    ]

Here, we set the width of the sidebar to whatever width is passed in from the view function.

We'll also want to add a function for the styles of the sidebar handle, like so:

sideBarHandle : List (Html.Attribute msg)
sideBarHandle =
    [ style "position" "absolute"
    , style "width" "5px"
    , style "height" "100%"
    , style "top" "0"
    , style "right" "0"
    , style "cursor" "ew-resize"
    ]

Resizing the Sidebar

This part I haven't fully figured out, but found a helpful discussion on: https://discourse.elm-lang.org/t/resizable-element-events/3999/5. The approach here is to listen for mousedown and mouseup events to determine if we're dragging the sidebar handle, and as long as we are, listen for mouse move events to find the mouse position.

Every DOM event in Elm produces a message of some kind that we have to define ourselves. We have all the message types in web/elm/src/Message/Message.elm. We'll need to add MouseDown DomID and MouseUp DomID to the possible messages here. We use DomID to identify the element that the message applied to. For that, we have another type in the same file. We'll need to add SideBarHandle to that type so we can say there was a MouseDown event on the SideBarHandle.

I mentioned earlier that the view function can give event handlers to DOM elements. We'll want to add the Html.Events.onMouseDown handler to our sidebar handle element, and instruct Elm to generate a MouseDown SideBarHandle event when the user clicks on that element:

Html.div ([ id "side-bar-handle"
          , Html.Events.onMouseDown (MouseDown SideBarHandle)
          , Html.Events.onMouseUp (MouseUp SideBarHandle)
          ] ++ Styles.sideBarHandle)
          []

We need something on our Model to keep track of whether or not we're resizing, and we'll need to update that field (let's call it isResizing) based on the messages we receive.

update : Message -> Model m -> ( Model m, List Effects.Effect )
update message model =
    case message of
        MouseDown SideBarHandle ->
            ( { model | isResizing = True }, [])

        MouseUp _ ->
            ( { model | isResizing = False }, [])

        ...

To handle the mousemove events, we need to use a different type of message that we call a Delivery. The difference between Message and Delivery is that a Delivery comes from a subscription rather than from DOM events.

...

---

Sorry, this explanation took longer than I was hoping. I'll try to finish this up soon. Hopefully this gives a decent starting point to whoever's interested

[rohithmn3]

@aoldershaw
The first approach might solve the issue but still not a good user experience as one should scroll to the end to adjust it every time.
If the 2nd approach is giving us much more control - then this would be the go for us.

It would be a great help if we get this feature soon.

[matthewpereira]

I actually think @aoldershaw 's suggestion would make a great first pass. I agree that being able to grab anywhere along the sidebar's edge would be preferable, but you don't actually have to scroll to access the UI 'handle' that allows you to resize the sidebar:

This would let us get this functionality into production a lot faster, and we can iterate to improve the experience over time.

In our MVP I'd also like to see this enhanced with a bit of javascript to record the user's preferred sidebar width to a cookie or local storage, to negate the need to adjust it every single time you load Concourse.

[aoldershaw]

PS I had only thought about it from the perspective of the dashboard...I'm not sure what else (if anything) is required to get this to work on other pages (though I'm guessing the dashboard may be the only special case due to the lazy-rendering of pipeline cards)

[matthewpereira]

We'd probably have to recompute things on the pipeline page, but that's an easily solved problem!

[matthewpereira]

I get the impression that manual intervention is the best solution, but I did think of another more semi-automatic solution. Just posting to get it out of my head and onto the page:

Setting some minimum and maximum widths might allow us to automatically expand the sidebar to fit the visible pipeline names on hover, and shrink it down to a less obtrusive list while the user is interacting with the rest of the dashboard:

This was obviously hacked together really quickly, so it's not the smartest CSS. I've set some really arbitrary and not totally beautiful widths here just for the sake of explaining, and the .gif doesn't show how smooth it can be in the actual browser, but basically the sidebar expands and contracts, adjusting its maximum width to the longest pipeline name in view.

It would require a lot more careful thought and testing to get the timing and interaction right. Just food for thought!

[aoldershaw]

I imagine this could lead to some undesirable behaviour where expanding the sidebar causes the pipelines to shuffle around if expanding/contracting the sidebar changes the number of pipeline cards that can fit in a given row

[matthewpereira]

I agree; I was thinking that since this is more on-demand only when a user is intentionally interacting with the sidebar by hovering it, we wouldn't necessarily need to reflow the pipeline tiles each time.

And I think it's just a more finicky solution in general. :\

[aoldershaw]

@rohithmn3 This was tackled in #5782, so the next release should allow you to enlarge the sidebar.

[rohithmn3]

@aoldershaw Thank you so much for this.