Improved inline expanded Editor

We know that the editor currently has an expand button:

However this edit mode is (as I believe it to) rarely used. This so, because it is a bad writing experience. You loose all your context for the sake of writing space.

I for one love to be able to scroll up and down, and have my writing experience stay consistent!

Proposal

I propose that we give this option for screens wider than >1280px, while the old "fully expanded" editor experience stays where it is for viewports smaller than that <1280px.

Instead of a full screen experience let's split up the view, possibly hide the sidebar (at even wider screens, it can be shown as well >1440px), and show the editor next to the existing discussion thread:

I propose to have this instead of the current full screen writing mode.

Implementation

I think this could be done quite easily, by manipulating the css with js.

cc: @awhildy @JobV @markpundsack @tauriedavis

@dimitrieh screenshot is broken. I support any initiatives to improve the zen mode.

@JobV it's an animated version of this screenshot:

@dimitrieh this is a cool idea! Not sure if it fills the same purpose though. The other mode was nice for small screens, this is only interesting for large screens.

Good improvement for larger screens

Interesting idea. Now if you could make it realtime collaborative, I'd be really excited. :)

Related, but I've often found that I edit issue descriptions but need to reference part of the comment thread, so I open up a separate tab for that since editing the description hides all the other content. Something like this might apply here.

Mentioned in issue #24873 (closed)

nice!

@markpundsack Editing a issue/mr description is a larger problem, as it isn't done in line, created an issue for this: https://gitlab.com/gitlab-org/gitlab-ce/issues/24873

@JobV yes I think it would be fair to keep the full screen editing experience for smaller screens and convert to this one from >1280px

@JobV are you okey with a label for improvements on the "editor"? Would love to be able to see all issues which improve upon the editor experience itself.

@dimitrieh no need to ask me, of course.

@dimitrieh this falls under @victorwu's responsibility, so you two should work together on these efforts.

Added ~14281 label

Added ~874211 label

Great idea @dimitrieh. UX improvements are so important, yet so hard to schedule in with all the awesome things we want to do. I'm working on getting some holistic view of priorities and issues (for Discussion features) in their various states of "readiness" for scheduling in and shipping. Take a look at the links at the top of the description here for context: https://gitlab.com/gitlab-org/gitlab-ce/issues/24688. If this is indeed a quick win, I'd push it higher.

@awhildy : Do you have any metas / epics for UX-ish type things that this issue can fall into? I'd like to compare this with any other ongoing things to see where it falls. And then I can shove it into our ready-for-work list.

@victorwu: Not sure I have the best system for that yet. A few of the bigger concepts are currently here: [meta] UX Opportunities. Happy to switch to using labels if that would be easier for tracking..

@dimitrieh: I've looked at this issue a couple times over the past few days, and I'm still trying to work through what my concerns about the design are. There is something that feels overly complicated about it to me. I start to have a little bit of this knee-jerk reaction when apps start to recreate 'window management' type functionality within them. I worry it is a flag that there are deeper concerns of the experience that we are punting onto users to manage themselves with switching states of the UI.

I am also not 100% sure what the scenario for this is. The vast majority of comments I see are 1-2 paragraphs at most. The comments that get longer (which I think both you are I are guilty of ) tend to be when we are exploring design flows, and may have a lot of pictures, and design alternatives in them. That feels like a symptom of the fact that we don't have a great solved problem for design discussions (https://gitlab.com/gitlab-org/gitlab-ce/issues/24816).

I know today we have 'zen mode' for the text input field. This zen mode makes sense to me on small devices, and maybe when someone is writing out the issue body. I think we can improve this zen mode even more, potentially adding Medium-esqe just-in-time controls for adding different type of content, or Confluence styled WYSIWYG markdown editing. The mode you are proposing has a different goal to me then zen mode. Zen mode is about removing distractions and letting someone focus. This proposal is trying to highlight the context even more, and give you the ability to scour through it while you write your comment. Is the core of this the fact that comment threads get so long, unwieldy, and are hard to parse and follow? Can we do something to make the comment threads simpler?

Don't mean to be negative -- just trying to challenge the goals of this. While it might be simple to implement, and easy to just add now, it feels like a different state/mode in our UI that could contribute to design debt as we try to work through some of our core UX discussion concerns. Does this make any sense, or am I just overthinking it?

@awhildy I kind of see what you are getting at! Although the problem is real. Even now that i am writing this very comment I am sometimes scrolling up to see what was said. I think this makes both the usecase as well as the problem.

Is this a problem of deeper concerns of the experience? I do not think this is for design discussions specifically in any case. It can be you want to follow up on the last 4-5 comments and you cannot have them all on screen. either due to your small screen, big comments, or just as they are always on top of each other. To me it feels like a natural wall of the digital medium.

The basic idea of this issue is a sticky editor to allow for more context while writing. (I do not think this is in any case wrong... this doesn't encourage creating long comments.. but rather empowers the user to be better informed while writing).

The bonus of the original issue is that it reflows the content in order for it to become sticky. Perhaps the bonus part is not even needed.

If we take a look at mobile UI, there has been an uprise in a new UI element. The sticky floating button/avatar of facebook messenger. People want to be able to comment in context of their other apps. Would such a direction be a better fit for gitlab's UI in your mind, preventing any reflow of content?

Love it that people such as yourself are critical on my issues, thats why I make them! To get something usable out of them.

example of sticky editor without the reflow of content:

That looks amazing

I have concerns with the fixed comment box. It takes up a lot of vertical space. This, combined with the top navigation being fixed, leaves little room to view the actual comments/content.

I often use the dock settings for Chrome dev tools in order to move them to where ever makes the most sense for what I'm working on. You are able to choose top, right, or undock to separate window

I'm not sure if this really needed for comment boxes but maybe providing a way to undock the comment box would help solve this problem without making things fixed.

@victorwu @tauriedavis found an example of where this is currently implemented in an existing application:

see example at http://sketchplugins.com/d/87-new-file-format-in-sketch-43/77 (you have to login)

i think this would be very nice to have!

i think they have a good default for vertical height (and some media queries in place, so this is not possible on screens which are too small) plus they have a minify button:

I think this could improve the writing experience considerably!

perhaps nice for 9.3 too look into

moved to gitlab#7133

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue