[Meta] Improving GitLab's Line Length

Title changed from Decrease fix width to Decrease fixed width

I would rather like to make it wider, because now some pages, e.g. Builds, do not fit well. It would be nice to have such option in the Profile settings.

I think it depends on the view. When reading an issue it is much easier to read with my example above. When viewing a larger data set (i.e. builds) you might need a wider 90% width.

Agreed. And the Builds page should be redesigned to fit into 1200px instead of making everything wider. That would be a better solution.

/cc @cperessini @tauriedavis

Added ~19492 label

This is a nice article with some numbers from StatCounter that look at comparing screen sizes with max widths. In the end they suggest somewhere between 1200px-1400px max width based on the % of users who will reach the max-width breakpoint and then states:

The smaller end of this range gives more users the focused center column, and would be more impactful on text-heavy content, and the larger end of the range gives more screen real-estate to fit more visual-heavy content on the page.

However, I think the problem happens when line lengths get too long. There is a lot of research on the best line length for readability- somewhere around 75-125 characters is considered ideal. Pages like the issues page have much longer line lengths which can slow down reading (but has no impact on comprehension) when at the max-width.

I do agree that pages that do not fit should be redesigned to fit/be responsive.

mentioned in issue gitlab-foss#20721 (closed)

Reassigned to @dimitrieh

Thanks @tauriedavis for bringing this issue to my intention. I already made an issue for human readable line length (for places where it makes sense) some time ago: https://gitlab.com/gitlab-org/gitlab-ce/issues/18808 . I will close down that issue and restructure this one to fit our needs (if you don't mind @emilsundberg )

Changed title: Decrease fixed width → [Meta] Fixed Width Mediaqueries and Human Readable Line Length

mentioned in issue gitlab-foss#18808 (closed)

mentioned in issue gitlab-foss#20914 (closed)

mentioned in issue gitlab-foss#20916 (closed)

mentioned in issue gitlab-foss#20917 (closed)

mentioned in issue gitlab-foss#20918 (closed)

mentioned in issue gitlab-foss#20919 (closed)

mentioned in issue gitlab-foss#20920 (closed)

Edited the main issue

cc: @tauriedavis @cperessini @hazelyang @jschatz1

Added meta in GitLab FOSS label

cc / @dzaporozhets

@dzaporozhets we should have a convo about this. This is certainly an interesting conversation.

mentioned in issue gitlab-foss#20680 (closed)

mentioned in issue gitlab-foss#18640 (moved)

This would be awesome to address in the next release ^^ @jschatz1 @dzaporozhets

Mentioned on Hacker News https://news.ycombinator.com/item?id=12338463

@sytses @tauriedavis @jschatz1 @dimitrieh few thoughts:

Current 1280px width for container is an optimal UI-wise. We should not make it smaller because we are building application with a lot of controls and different UI components. 800px is ok only for websites that are pure text.
Inside current 1280px container we can increase readability by manipulating font-size, padding and maybe a bit of width of particular text block.

Example

2 screenshots with same amount of characters per line made on 12" laptop.

Limit container width approach. As you might see it immediately creates extra work since some information wont fit in one row with a buttons. Imagine how it can affect other pages like merge request with a lot of tabs and other controls.

Increase font-size and adds extra right padding for issue description. It has minimal effect on existing UI, no white space around text and still solves readable line length problem.

@dzaporozhets good points, though let me get into this :)

1

This issue is not precisely on to decrease the container width as I think that is fine. 1280px is definitely an ideal width approach UI-wise (exactly the window width of 13" macbook pro). However it does try to create an optimal line length by introducing white space where its needed through padding.

For example in the following subissue: https://gitlab.com/gitlab-org/gitlab-ce/issues/20916 we can see the design mockup for an optimised layout for issues/MR. It actually leaves the 1280 container alone and uses padding in certain places to create white space.

I agree 800 px is okay for websites that are pure text, that is exactly the reason why I introduced this issue. Each sub issue offers an optimized design for a gitlab page that is mostly only text and would thus need this.

Also on a pure text based website the width would have to decrease even more than 800px, or to quote myself:

GitLab is a different medium and holds a lot more different kinds of content. Therefore the amount of characters on a line can be longer then 75-90. I have done some research previously and I think we can say 110-130 characters is a OK.

2

In the previous number I already noted that padding is a better solution than tinkering with the container width. As for font-sizethis can indeed improve the circumstances, but I would use it with caution as it could create a slight imbalance in the whole UI typography. Plus it would introduce the following: "Should we increase font size again if we hide the sidebar?".

I think a fixed max width for text is the best way to go (based upon which font-size of course) made possible through padding.

To get back to the white space issue vs font-size:

It could be that the line length would be ideal on a 12" laptop, but what about the whole spectrum of devices with different screen widths? Apart from that, I saw that @sytses posted a comment from hackernews which says the following:

GitLab defaults to letting text lines be overly long and this just makes the whole thing feel uncomfortable even if you think you don't mind it.

I can sort of agree with this, its the purpose of this issue. Not every inch of space should have to be filled with information (although on smaller screens this is more likely to happen). White space creates focus and clarity, it eases the mind into a better comprehension of the situation/page at hand. Or to quote treehouse:

Whitespace is also associated with elegance and sophistication since it is a way to organize text, organize elements and guide users attention to certain elements. - treehouse

I want this to have a minimal effect on the existing ui, but do solve the current problem through the designs created in the subissues.

We could do a small poll in the slack channel with the following image:

with sidebar:

or without sidebar:

lastly, we could truncate the following:

with ellipses or leaving away "opened"(or changing date appearance to 23-08-2016 or something) etc we got quite a few options should we arrive at a (small) width that not ideal although I think we are fine if we keep the specifications in the original post.

what do you think?

Milestone changed to %8.12 in gitlab-foss

We should actually set up a staging version of this to try it out. @jschatz1 with whom can I work together on this?

mentioned in issue gitlab-foss#21442 (closed)

@dimitrieh too much side padding on your proposal. Visually it looks bad with full-width lines and narrow text column

@dimitrieh again my proposal was width limitation for text, not whole comment row or header

@dzaporozhets can you elaborate on your comment with the image? Do want the block length to be the same, with just the linewidth shortened also as it wrappes.. say to the length of the red bar at the top?

I think I see what you mean.. let me get back to this later

@dimitrieh yes my point is that we don't want to affect whole UI element (1st red rectangle) but only text block (2nd red rectangle).

For example we can try to achieve better Readable Line Length by:

20% shorter (width) text block
15% bigger font-size for 1200+px browser window
..something else

which in total gives us improvement to readability (not best like 800px width but still) that does not affect UI much.

@dzaporozhets I think this discussions primary focus is the issue/mr page as that one is the most difficult to get right. Lets get that one down, then the rest of them.

I played around with your proposal of bigger font sizes and shorter text blocks and although it seems a good idea, it isnt going to work imo (it will throw the UI out of balance):

I get the point of not wanting to meddle with the UI style to much. However all these views, where Issue/MR are the most important ones, need a different set of rules.. or at least an adjustment based on the old rules. They are exceptions.

to give a few visuals on how i think it should look:

rules adjustments:

1280px becomes max width
text plus styles take up max 790px
centered but with offset from right sidebar

1440px width screen:

1024px width screen:

I know you are worried about the amount of white space, therefore I am trying to set up a test version of gitlab where such an implementation can be seen..

to see it live is different then to see a live version

Setup a staging DO droplet, wont be online for long atm but here you can see a implementation

http://82.196.4.85:3000/gitlab-org/gitlab-test/merge_requests/9

or

http://82.196.4.85:3000/gitlab-org/gitlab-test/issues/8

the added css of course generates lots of issues in other visuals

I think @dzaporozhets's original idea was something like this, which I think works well, but only for the body of the issue.

If you only restrict the content in the comments it looks like this:

To me, that version of the comments really doesn't work. It feels like it's all over the place and there's no order.

I do like the style for the Merge Request page in the droplet. There can be a lot of whitespace, but the content is much more readable and it's very compact.

I don't like the Issue page because of the full-width lines. I think they should be as wide as the content they delimit.

@cperessini yes plus making the text bigger... imo both do not work

@dimitrieh I pressed Comment by accident before. I added some thoughts on the droplet pages

Yeah, I wanted to include a screenshot so we could see what it would look like. Making the issue header narrower makes everything fit better together, but I think the long name problem is a real concern. Maybe we can restructure the header to make up for the lost space.

Can you share a login to the droplet in Slack so we can see what it looks like with the buttons? (you can't see them if you're logged out)

mentioned in issue gitlab-foss#13723 (moved)

Me and @cperessini talked a bit on slack and came to the conclusion that adjusting the fluid container is actually the best option in this case as its the most simple and everything stays balanced.

As making a live version of everything is quite hard, I played around with some of the options:

basically it makes the fluid container 822px long (790 +16px padding + 16px padding), also I in some cases I have centered the column more to the right to make up for space of sidebar, plus changed colors here and there.

best ones

are basically the simplest ones:

really centered column due to it being narrower, so making up for small sidebar.

when sidebar is open, it loses that extra space and just makes the view asymmetrical:

the symmetry may be resolved automatically if we'd introduce the following implementation of the octotree sidebar: https://gitlab.com/gitlab-org/gitlab-ce/issues/13723#note_14771619

I agree with the one you chose for the collapsed sidebar, but I like this one better for the expanded one:

I think it's better to keep the content centered with the nav bar, even if it creates some imbalance in the whitespace.

Maybe if we keep everything in the issue description the same except the content and add a border it would work okay.

It seems like the comments is the most tricky section. Perhaps if we shortened the text contentwidth (p, ol, ul, etc) but left everything else the same. I think this is what @dzaporozhets was proposing.

cc @dimitrieh @cperessini

@tauriedavis on what resolution were you testing this?

I still think this is an inferior solution, it looks okey with the image, but without it looks weird. Also the main issue bodytext within the border feels... wrong

With the text block shortened, it is strange as the user is in no way informed that the text can't flow further/longer....

@cperessini interesting choice!

thanks @tauriedavis & @cperessini for thinking along already.. this is a hard one to crack!

As for the image getting lots of screen real estate.. this is fine if the image fits within the viewport still for its height. if the aspect ratio of the image is for lets say 9:16 it would create less ideal image visuals... in that case not even for the image we would want the container that wide...

I am however for an inline expand button for images and codeblocks, which I did a small mockup for a long time back: https://gitlab.com/gitlab-org/gitlab-ce/issues/18544#note_12666313 . In other words this would give the user the ability to let the image become really big without having to open another tab.

@hazelyang what are your thoughts on this issue?

Maybe a combination of @tauriedavis's issue body and @dimitrieh's comment section? That way we have space for a long name in the header and the rest is compact.

@cperessini

we have space for a long name in the header

I still think we can display the date differently or at least truncate it if necessary.

opened about 6 months ago can become 6 months ago can become 2016-03-01 or even 16-03-01

Proposed design:

If screen size >= 1280px, we limit the width of container to 958px.
If screen size < 1280px, the container still works the way responsive.
Change the length of paragraphs on issue body and comments to 700px.

What we can solve

The layout doesn't feel balanced from the visual perspective.
Not good readability.

Just my suggestions, hope it's helpful.
@dzaporozhets @tauriedavis @dimitrieh @cperessini

1280*800px

1440*1020px

1920*1200px

@hazelyang this doesn't look that bad actually, probably because of the golden ratio..ratio (or close to) ;) (its a bit the same as tauries and dz's)

would love to know what other think of this... as there is still no particular clue to why the text cant flow further.. ;)

A good thing from this is, that images can still be big

@tauriedavis @dimitrieh I think @hazelyang proposal (https://gitlab.com/gitlab-org/gitlab-ce/issues/13680#note_14865026) is the best one so far.

For what it's worth, I also agree with @dzaporozhets here

To give a feeling: a live view of how this could look at your computer: CLICK HERE (found a new easy way to create fast live html previews)

I say we get this to front end

With the following kind of decided:

https://gitlab.com/gitlab-org/gitlab-ce/issues/20916 Project Issues & MR's

I was wondering about the projects view:

https://gitlab.com/gitlab-org/gitlab-ce/issues/20914 Project Home README.md

What if we introduced a sidebar, so we can introduce the same design hazel proposed for the issue/MR view into that one?

Most important point of this is that the Project Readme, is now around 60% viewport height instead of 30%-40%, makes the projects view more usable imo.

what do you think

I also propose we get this to frontend so we can implement it and gain feedback quickly. I think we will have a better idea for improvements after spending some time with it in development.

I couldn't review this very long thread but searched and didn't see any consideration of this idea: just use a max-width on <p> elements so all long-form text in any context conforms to readable line-lengths.

Thanks @wolftune! That is part of the proposal seen here https://gitlab.com/gitlab-org/gitlab-ce/issues/13680#note_14865026 :)

@tauriedavis I don't see that in the proposal. I only see containers mentioned, and not the idea of putting CSS directly on <p> or on [some container] p as a possibility…

@wolftune: Under Proposed design see the third bullet point.

Change the length of paragraphs on issue body and comments to 700px.

Also, I proposed it in my comment above as well:

Perhaps if we shortened the text contentwidth (p, ol, ul, etc) but left everything else the same.

This is what you mean, right?

@tauriedavis no, I meant specifically a max-width. That only needs to be set once, and it will control that limit regardless of containers or responsiveness. I mean, I guess that could be the implementation of the sentence you quoted, but that's not clear. Point is: I was just suggesting an implementation of CSS for consideration (not certain it's the way to go though).

@fatihacet I think we should get this to front-end for the issue/mr comments view based on hazels version as this is marked for 8.12: https://gitlab.com/gitlab-org/gitlab-ce/issues/13680#note_14865026

We can later on focus on the general project view readme and the other views mentioned in the original issue body

cc: @tauriedavis

On a sidenote, this issue will have much benefit when we can finally use review apps https://gitlab.com/gitlab-org/gitlab-ce/issues/21971

Added frontend in GitLab FOSS label

Mentioned in issue gitlab-foss#20916 (closed)

Milestone changed to %Backlog in gitlab-foss

cc: @awhildy

unassigning myself for now

Assignee removed

Mentioned in issue gitlab-foss#22689 (closed)

Mentioned in issue gitlab-foss#23125 (closed)

Mentioned in issue gitlab-foss#23734 (closed)

Reassigned to @mikegreiling

Milestone changed to %8.14 in gitlab-foss

Just to be on the safe side here @mikegreiling you are going to tackle only the discussion views isn't it? like on issue/mr ?

@awhildy that's what is intended right?

Mentioned in issue gitlab-foss#21302 (moved)

@dimitrieh yes, I'm grabbing gitlab-foss#20916 (closed). The rest of these sub-issues are all tagged with UX in GitLab FOSS still, so I presume they aren't ready.

Assignee removed

I think the description needs to be updated with first steps and a link to that issue. The sub issues will be tackled after this first iteration - right @dimitrieh? From the current description, it's not clear what the course of action is.

Removed frontend in GitLab FOSS label

Reassigned to @dimitrieh

@tauriedavis Yes this issue has become sort of a mess, I say we wait for the implementation of https://gitlab.com/gitlab-org/gitlab-ce/issues/20916 and pick this issue up again next release

I updated the main issue body to reflect this.

@awhildy I updated this main issue body. We should get rid of the milestone for this issue as it will probably span multiple milestones.

Assignee removed

Changed title: [Meta] Fixed Width Mediaqueries and Human Readable Line Length → [Meta] Improving GitLab's Line Length

Mentioned in issue gitlab-foss#24344 (closed)

Milestone changed to %8.15 in gitlab-foss

Mentioned in issue gitlab-foss#20680 (closed)

Milestone removed

Milestone changed to %Backlog in gitlab-foss

changed milestone to %8.15 in gitlab-foss

mentioned in issue gitlab-foss#25663 (closed)

marked the task https://gitlab.com/gitlab-org/gitlab-ce/issues/20916 Project Issues & MR's %8.14 in gitlab-foss as completed

mentioned in merge request gitlab-com/www-gitlab-com!4007 (merged)

Hi everyone,

These modifications enforcing to all users the width reduction some parts of Gitlab UI is a really big regression in term of usability. Gitlab is a product for everyday work in computer field, with a lot of information to display. One of the main Gitlab pros point is the ability of the UI to display a lot of information. Nowdays, most peoples in software development have big wide screens with high resolution, intentionally to display a lot of information in a single sight.

The limited width in Issues is a waste of space (a lot of white unused space, about half of the width here). It's a bit condradictory with recent effort on using empty space, or the foldable issue sidebar (which was a greate feature to gain some space displaying issue content).

I think this really should be a per user option everyone can enable in his user profile, but please don't enforce it.

Hi @orobardet, thanks for your feedback. Can you let us know details with examples in which context you miss information overview since GitLab 8.15?

The latest improvements relate to the issue and merge request views which are mainly text based, and this is only the first iteration. An unlimited content width based on the available viewport never is a good idea for readability, so I am very excited about the UI improvement here. To me, this change respects the readers' cognitive resources for catching up with content. Considering the importance of this change for user experience, I think it's not a good idea to make this configurable at all.

GitLab doesn't try to artificially hold back complexity where needed, so any use cases are appreciated.

changed milestone to %8.16 in gitlab-foss

changed milestone to %9.0 in gitlab-foss

mentioned in issue gitlab-foss#28041 (closed)

added ~1434245 label

@awhildy should this issue have %9.0 in gitlab-foss ? as its a meta in GitLab FOSS ?

https://gitlab.com/gitlab-org/gitlab-ce/issues/20914 could for example be done already, similar to https://gitlab.com/gitlab-org/gitlab-ce/issues/20920 and https://gitlab.com/gitlab-org/gitlab-ce/issues/20919 and perhaps also https://gitlab.com/gitlab-org/gitlab-ce/issues/23734

removed milestone

Thanks @dimitrieh!

Yep, all of the sub issues that aren't implemented do have UX completed on them, and are ready to go.

added frontend in GitLab FOSS label

@awhildy who will schedule them ?

If someone from @jschatz1 team has time for in 9.0 that would be awesome (maybe @annabeldunstone?).

If not, @mydigitalself - we should get this improvement in as soon as we can. When I asked Chris from Codepen to elaborate on what he meant in his podcast about polish, line length was one of the two things he mentioned (https://gitlab.com/gitlab-org/gitlab-ce/issues/28041).

I might have time for 9.0 but not sure yet

@awhildy my only concern is that the specific proposals all seem to be in a world where the top-level menu navigation is centred and I know there are proposals to move it to the left and how does this work in that world or do we have to change it again very soon?

My second comment is that the proposal has a max-width of 790px, which seems a bit small to me. For reference, GitHub have a 980px primary container, heavily padded to leave 888px for the README content - they also us a larger point size on README (16px) than they use elsewhere (14px).

Also note there's always preference here for full-width, despite its impact on readability.

Thanks @mydigitalself!

The plan is to left align the nav with the content block, so that shouldn't be a problem (https://gitlab.com/gitlab-org/gitlab-ce/issues/27934)
We have a setting for full width in preferences. Fixed width should remain the default due to the improved readability, but it is easy to switch to full. With a call out being added (https://gitlab.com/gitlab-org/gitlab-ce/issues/27269), people will be more aware of being able to switch to full if they desire
Comparing sites that use the system font, we decided 14px was the right base font (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7905).
We switched issues to a width of 790px several releases ago. That seems to have worked well, and I'm hesitant to change that up unless we hear more feedback. Having a larger width makes sense with a larger font size -- but it doesn't make sense to a 16px base font for all of GitLab. Happy to discuss if READMEs should be a special case and have a larger base font, though.

We switched issues to a width of 790px several releases ago...

@awhildy that's not what I'm seeing in gitlab.com (using default Fixed setting). Issue content is 958px

Good catch. You are right. The design for issues (gitlab-foss#20916 (closed)) landed with:

If screen size >= 1280px, we limit the width of container to 958px.
If screen size < 1280px, the container still works the way responsive.
Change the length of paragraphs on issue body and comments to 700px.

However, the paragraphs seems to have been pushed to 883px when all the padding and everything taken into consideration:

My intent with finishing this work is that we bring all of the other pages to this same width as issues. @hazelyang @tauriedavis @dimitrieh - Does that make sense? Any concerns with that?

Yep, we have the variable $limited-layout-width that just needs to be applied to the rest of the pages so they are all the same.

mentioned in issue gitlab-foss#27934 (closed)

I have no concerns with making everything consistent. I don't have a heavy preference between 700px and 883px for issue body content. I just tested it myself and both appeared just fine, although consider that 883px gives ~130 chars vs ~105 so the former is pretty substantially (~60%) over recommended line length.

Although it does look a bit weird with a longer text input box than the line length of the comment above don't you think, or am I just being pedantic?

mentioned in issue gitlab-foss#29958 (closed)

mentioned in issue gitlab-foss#30920 (closed)

Yeah, I think shortening the line length and not the container looks weird. I've improved the markdown styling here which I think will help with readability without further shortening the line length. https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10350

added Deliverable in GitLab FOSS label

changed milestone to %9.4 in gitlab-foss

changed the description

closed

@filipa @iamphill I am going to close this issue, as the individual issues are all scheduled and can be managed on their own.

@dimitrieh this can't be closed like that, this is a Deliverable in GitLab FOSS :)

This should only be closed when all the issues are ready :)

Not all the issues in this meta issue are scheduled

reopened

marked this issue as related to gitlab-foss#35730 (closed)

mentioned in issue gitlab-foss#35730 (closed)

moved from gitlab-foss#13680 (moved)

[Meta] Improving GitLab's Line Length

Resources

Designs

Child items ...

Activity

Example

1

2