Too small scrolling text area when entering issue bodies and comments

[JohnVeness]

When entering the body text for a new issue, or a comment on an existing issue, we only have space (depending on device) for about four lines of text. Even though we can scroll within that, it's very cramped.

When clicking the edit button next to an existing comment, we get a much larger text editor to work in. It would good to be able to somehow use such an editor when first creating issues or comments.

[Tunous]

In case of comments we could add expand button on the left side of the comment box. For issue body perhaps that could be located in the toolbar.

And expanded editing screen could be improved to contain edit and preview tabs that can be switched between.

[maniac103]

For issues, I have thought of moving the input box our of the header and into the content pane below. Would allow for infinite expanding.

[Tunous]

Sounds like a good idea. But I would also like to see an option to switch between edit and preview modes as that's a nice feature I miss from GitHub web version. Perhaps it would be possible to add a pager here and the tabs would be located next to the apply button.

[maniac103]

Even nicer would probably be a preview button that opens a 'sheet' (like its done when opening a contact from the contact list)

[Tunous]

'sheet' (like its done when opening a contact from the contact list)

Not sure how that is supposed to look. Got an example?

[maniac103]

Not at the moment, but I mean this: https://material.io/guidelines/components/bottom-sheets.html

[Tunous]

These bottom sheets don't convince me. I can't think of a nice way how to implement this using them. My idea with ViewPager tabs would allow for previewing how the output will look like without any clicks. Just type text, scroll to see how it looks, scroll back and continue typing. It has much more potential than bottom sheets as it could be made so the keyboard stays visible. In the case of bottom sheets, I assume it would be closed as these appear at the bottom of the screen.

Similar ViewPager behavior is implemented in Simplenote app but it does close the keyboard. It works by auto-saving and updating markdown when users stop typing for some time which makes it so the preview stays up-to-date.

[Tunous]

I just saw a new android GitHub application FastHub which has a very nice markdown editor similar to what I had in mind. The difference is that it has preview toggling done with a button instead of a pager. I still think that a pager is a better option though.

What is also nice is how editing issue body works. At first it appears to have a small editor but when you click on it, it opens in full screen. This is something we could steal instead of moving the body field out of the header.

And finally it has few buttons that allow for inserting markdown elements. It's worth stealing this too 😉

---

I think I have a solid idea of what I would like to implement here now. I'll start a work on it in the coming days. Let me know if you have any further ideas or disagree with something. @maniac103

[maniac103]

Uh, I think I misunderstood you all this time :-/ the bottom sheet idea was targeted at entering issue comments. As for the issue body editor, I'm not a fan of his 'dialogification' of everything. I'd definitely much prefer keeping the editor in place. I wonder whether we should keep the editor as-is and have an 'advanced mode' button open a dialog (or bottom sheet ... I think it's useful in that case, and more naterial-y and less busy than a dialog), in which I think using a ViewPager indeed is a good idea. And yes, +1 for adding some buttons for entering markdown elements there, even though it'll make the lack of image upload even more obvious ;) The preview pane could consist of a WebView using showdown to render the entered text. That advanced mode button also would work just fine for the comment editor.

[Tunous]

Hmm, I can't really get into how exactly you would want to use that bottom sheet. In my mind the editor should take whole screen just like other screens and not be a dialog or bottom sheet.

Let's list what my idea is:

Comment field for issues would stay how it works currently but with an additional button to enter advanced mode. I'm not sure where exactly the best placement for that button would be but the left side seems to be the best option.

The advanced mode would be a full screen activity with pager. One page for editing and one for preview. (And we could add these markdown element insertion buttons here too.)

Issue editor can gain additional toolbar button to enter advanced mode to edit body. The same one used when entering advanced editing of comments.

[maniac103]

My thought is almost the same, except that the advanced editor mode is not a full screen one, but keeps its parent (e.g. issue editor) partially visible - in other words, a bottom sheet ;) I'm totally fine with it covering say 75% of the available height, I just would like it being obvious it's linked to the parent. (NB: the issue comment editor should probably be made to behave the same way). I don't really understand the toolbar button idea yet, can you expand on that? In general I think toolbar buttons should only be added for actions that apply to the whole activity, so I'm not sure a toolbar button for e.g. issue body editing is a good idea. It's probably a secondary concern either way though.

[Tunous]

I'm totally fine with it covering say 75% of the available height

I see now. But I feel like there would be a problem of accidental closing. Bottom sheets have that thing that they can be scrolled down to close and I think that would be terrible for our use case as users could accidentally close it when selecting text or scrolling. Perhaps if it was possible to lock the bottom sheet to be close-able only via button that could work.

You can think of the toolbar button as a way to enter advanced editing mode. I think it fits to the whole edit activity as the only thing that could be advanced here is the issue body itself. Icon for it could be a rectangle with corner arrows showing that it can be expanded or similar.

[maniac103]

That swipe-to-close is (as far as I understand) something we'd have to code manually anyway, so we could just omit coding that. I agree that behaviour would be a bad idea for us.

[Tunous]

I was thinking about the bottom sheet dialogs all the time but there are also persistent bottom sheets. Perhaps they might work for the comment editor. I think they are always visible on screen and can be only scrolled to expand/collapse.

[Tunous]

I experimented with a persistent bottom sheet for comments input box and it kind of does work. But there is an issue with toolbar auto-hiding that I can't find a way to solve right now.

Notice the blank space that pops up under input field. It has always the same height as the collapsing part of the toolbar.

---

There is the code for it: https://github.com/Tunous/gh4a/commit/a5a787763265434786c51187964189e82f9969fb but it's a bit hacky because the bottom sheet layout has to be put directly under the CoordinatorLayout which is present in the main screen. I don't think that's a good way to go with this...

[maniac103]

CommentBoxFragment adds a listener to AppBarLayout and adjusts its padding to compensate for this. You'll probably need to do the same thing there.

[Tunous]

Some progress:

[Tunous]

It's slowly turning out nice:

@maniac103 Question about edit comment action. Should it be changed to use this "inline editor" or keep opening full-screen activity? Also what do you think about this so far?

[maniac103]

@Tunous :+1: It's looking great! The tab bar maybe could be tweaked a little, but that's minor details. I'd definitely like to see the comment editor being converted to use this. Maybe an 'expanded' mode where the editor is set to minLines=10 or something (alternatively adjust height so that top is at say 20% screen height) would make sense?

[Tunous]

I thought about doing this when the user selects to edit a comment:

• Highlight the comment they are editing with colored background
• Put the content of selected comment into the comment editor
• Show a button for discarding comment editing (No idea where would be a nice place to put it)
• Change the appearance of send button to represent edit action (What would be a good icon for that?)
• Add text saying that a comment is being edited?

There is no need for minLines or adjusting the height as the editor nicely wraps to the size of comment/preview text. Blank space would just make it unnecessarily waste space.

[maniac103]

Some additional space wouldn't hurt IMHO, as it gives more room for touch actions like copy'n'paste, scrolling or selecting text. I also thought of this being either done optional (via button) and/or selectively (e.g. comment editing could always use that), so 'wasting' screen space wouldn't really be a concern.

[maniac103]

Oh, and BTW, don't forget the preview might need more room then the editor.

[Tunous]

Got the preview functional but there are still a few issues left to solve. There is also a problem with the tab bar as I can't find a way on how to make it sticky. Currently, it appears only when you scroll the whole content down... We might have to replace it with something else if we can't find a way to fix that.

Also experimented a bit with the send button. The current version didn't work well as it took away a lot of space from the comment editor and was not accessible when content is long. I replaced it with a floating action button that is fixed at a specific location in a way which makes it appear either connected to the top of the bottom sheet or tab bar. Also made so it disappears with an animation when there is no content to send.

Thoughts?

[taltstidl]

@Tunous Not sure what you are using for the preview, but it might make sense to use the Markdown API provided by GitHub. This would make the preview most authentic. Just a thought...

[maniac103]

@TR4Android I'm not sure this is a good idea, as it means one server request per newly entered character. Without having looking I'd guess he uses what we use for markdown rendering elsewhere: a WebView running showdownjs.

[maniac103]

@Tunous I'll play with your work and let you know my thoughts. From the GIF I'd say the FAB works, but the sheet layout needs some improvements to make it look good - e.g. the top line is way too thin now, and the 'expandability' needs limitation (sheet shouldn't span full height so that it's always differentiable from the actual content). Maybe also add some elevation to it?

[maniac103]

It just occurred to me that the Google+ app gets the comment box layout pretty right, and that its layout likely also would work pretty well for us. It hides the controls/buttons by default and only shows them when focussing the comment editor. Maybe that behaviour is worth a thought? It certainly looks less 'busy'.

[maniac103]

Another app to look at might be Tapatalk - they do the 'expand' button thing I was mentioning earlier.

[Tunous]

Yes, I'm using a WebView running showdownjs. It shouldn't be a problem since we can tweak the output with css to make it appear just like the final comment.

@maniac103 The code is in this branch: https://github.com/Tunous/gh4a/tree/comment-bottom-sheet.

[maniac103]

Hmm, the FAB definitely doesn't feel 'right' as it is now - as long as the comment area isn't filled, its placement looks kinda random, and when it's filled, the FAB obscures some text. The more I use this, though, the more I think we should keep preview etc. to an 'advanced' mode, because I'm pretty sure most people won't use markdown in comments to begin with. Tapatalk's behaviour probably would fit well (they're doing the same thing, just with bbcode instead of markdown), just needs some UI tuning ... I still think my earlier idea (https://github.com/slapperwan/gh4a/issues/365#issuecomment-284249230) isn't too bad :) What I definitely like about your current approach is that it allows swiping the comment box out to read earlier comments; we should definitely keep that. And BTW, where did the markdown tag insert buttons go?

[Tunous]

Hmm, the FAB definitely doesn't feel 'right' as it is now - as long as the comment area isn't filled, its placement looks kinda random, and when it's filled, the FAB obscures some text.

Yeah, I think I agree with you here but I can't think of a better implementation...

Tapatalk's behaviour probably would fit well

Got an example for this? I don't use that app and don't really want to install it ;) Right now I'm not really sure how the advanced you describe would look like.

And BTW, where did the markdown tag insert buttons go?

That was just a placeholder text to see where it could be placed. I left work on it for later time once we decide on the UI.

[maniac103]

Got an example for this? I don't use that app and don't really want to install it ;) Right now I'm not really sure how the advanced you describe would look like.

Sure. 'Quick response' mode: https://drive.google.com/open?id=0B0hmLAh3l4oHVENUVW9FamRSLWM 'Advanced' mode (reachable by the button to the left): https://drive.google.com/file/d/0B0hmLAh3l4oHYWZ3TktfWFI5QkU/view?usp=sharing

Alternatively: G+: comment box without focus has no buttons: https://drive.google.com/open?id=0B0hmLAh3l4oHalVad0pLaHB2TWM after getting focus it gets advanced controls: https://drive.google.com/open?id=0B0hmLAh3l4oHZ3J3OGVYRDF6dUk

I think I prefer the simple/advanced mode mind set, but the send button placement in G+ may be worth a thought?

[Tunous]

I see. I like that G+ approach too. It's fairly simple to add, so there would appear advanced mode and send buttons at the bottom.

The problem is with the advanced mode though. Using full screen like in Tapatalk will disable the possibility of seeing other comments. We could make the expand button reinflate the content of bottom sheet with the pager and other stuff. But for it we have to find a way to add sticky header/footer to bottom sheet to solve the issue mentioned in https://github.com/slapperwan/gh4a/issues/365#issuecomment-287481615

[maniac103]

Yeah, I wasn't suggesting to put advanced mode to a separate activity, I was more heading at their button placement. About the tab bar, why not move it to the top in advanced mode and constrain collapsing to e.g. twice its height so the tabs + a bit of editor are always visible?

[Tunous]

About the tab bar, why not move it to the top in advanced mode and constrain collapsing to e.g. twice its height so the tabs + a bit of editor are always visible?

Not sure if that won't have similar issue, but might be easier to find a fix. I'll try that later.

[taltstidl]

@maniac103 I thought the preview is only created when switching to the preview tab, not for every character that is entered. This is how I think the once official PocketHub app does it, it renders the preview using the Markdown API and a TextView. I'm happy though with any solution that generates accurate previews. Keep up the good work :+1:.

[Tunous]

Ok so I managed to fix the issue with sticky views and there is what I came up with:

First of all, I've made the bottom sheet work in 2 modes that you can switch between at any time: advanced and basic.

Initially, the bottom sheet is in the basic mode consisting of an expand button (that pencil icon is just a placeholder), an input field and a send button. You can type in here and the bottom sheet will adapt to the size of the content. It's pretty minimal. I guess we should also add max lines limit here too, but I'm not sure how big.

Then once you press the expand icon the bottom sheet animates and you get the advanced mode. It's set to take almost full size leaving some space to see other comments (will need to calculate that height based on device, right now it's 400dp for content) and has all the advanced options available. In the gif you can notice that the basic mode input field disappears. It's where later the markdown editing buttons will appear.

Let me know what you think about this version :)

[Tunous]

For issues, I have thought of moving the input box our of the header and into the content pane below. Would allow for infinite expanding.

To expand on this idea for issue editor. The body field could be moved as you mentioned and the content pane could be turned into a ViewPager with 3 pages:

• Body - Markdown body editor
• Preview
• Options - The options that are present under header in the current version of this editor

[maniac103]

This is much better and pretty much what I thought of :+1: A little tweaking here and there and filling the gaps and this is good to go, at least judging from the gif. About the issue editor, that proposal sounds fine to me.

[maniac103]

Got around to trying it, definitely worth a 👍 I think that's the path we should follow.

[maniac103]

Having said that, I have to add that it isn't possible to add comments in its current state. ;) Other issues I noticed: text editor auto completion doesn't work, and entered text isn't synchronized between basic and advanced mode.

[Tunous]

Yeah, I know. I first worked on the interface so the behavior is left broken/disabled/etc. I'll finish the rest once I get more free time again.

[maniac103]

Another thing: pull-to-refresh is broken

(Just listing stuff I found here so that we don't forget)

[Tunous]

Improved by #536