Focus topic input first when opening compose box

[gnprice]

In a channel feed, if you tap the compose box and the topic input is empty (i.e. you haven't already entered something there), we'd like to put focus in the topic input instead of in the content input.

Chat thread here: #mobile > reply goes to "no topic" @ 💬

Background / motivation

This bit of user feedback started that same thread:

Hello, a new user / first time poster with some hopefully useful feedback : we moved a small organisation to Zulip recently and the thing we keep banging our heads on is accidentally posting to [no topic] when we meant to reply to a comment in some topic.

In the legacy app we effectively have the behavior this issue is calling for: when the compose box is closed, the topic input doesn't even appear, but once you touch it so it opens, your focus goes to the topic input.

References

• #mobile > reply goes to "no topic" @ 💬
• An issue that may make this change less effective, until it's resolved:
  autocomplete: Options list can persistently lag behind query #226

[shkshreyas]

About improving the user experience in the Zulip mobile app by changing the focus behavior when opening the compose box. my solution for this issue.

Solution for Compose Box Focus Issue

The issue requires changing the focus behavior when tapping the compose box so that if the topic input is empty, focus should be placed on the topic input instead of the content input.

This change would help prevent users from accidentally posting messages with "no topic" when they intended to reply to a specific topic.

Here's how we can implement this solution:

// ... existing code ...

class ComposeBox extends StatefulWidget {
  // ... existing code ...
}

class ComposeBoxState extends State<ComposeBox> {
  // ... existing code ...
  
  // Add or modify the method that handles tapping on the compose box
  void _handleComposeBoxTap() {
    // Check if the topic input is empty
    if (_topicController.text.isEmpty) {
      // If empty, focus on the topic input
      FocusScope.of(context).requestFocus(_topicFocusNode);
    } else {
      // If topic already has content, focus on the message input as before
      FocusScope.of(context).requestFocus(_messageFocusNode);
    }
  }
  
  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      onTap: _handleComposeBoxTap,
      child: Container(
        // ... existing compose box UI code ...
        child: Column(
          children: [
            TextField(
              controller: _topicController,
              focusNode: _topicFocusNode,
              // ... existing topic input properties ...
            ),
            TextField(
              controller: _messageController,
              focusNode: _messageFocusNode,
              // ... existing message input properties ...
            ),
          ],
        ),
      ),
    );
  }
  
  // ... existing code ...
}

Additionally, we should ensure that the focus nodes are properly initialized:

class ComposeBoxState extends State<ComposeBox> {
  final TextEditingController _topicController = TextEditingController();
  final TextEditingController _messageController = TextEditingController();
  
  // Add focus nodes if they don't already exist
  final FocusNode _topicFocusNode = FocusNode();
  final FocusNode _messageFocusNode = FocusNode();
  
  @override
  void dispose() {
    _topicController.dispose();
    _messageController.dispose();
    _topicFocusNode.dispose();
    _messageFocusNode.dispose();
    super.dispose();
  }
  
  // ... rest of the implementation ...
}

This implementation will check if the topic field is empty when the user taps on the compose box. If it is empty, focus will be directed to the topic input; otherwise, focus will go to the message input as before.

The change is minimal but should significantly improve the user experience by reducing accidental posts to "no topic".

[kelseafunwi]

Wanted to contribute to this issue but the above solution I think should solve the problem well.

[gnprice]

@shkshreyas It looks like you asked ChatGPT or another LLM how to solve this issue, and then just pasted its response into the comment box. That isn't useful.

@kelseafunwi Sure, welcome. Take a look at our guide to contributing to Zulip:
https://zulip.readthedocs.io/en/latest/contributing/contributing.html
and in particular the steps here:
https://zulip.readthedocs.io/en/latest/contributing/contributing.html#picking-an-issue-to-work-on

[shkshreyas]

@shkshreyas It looks like you asked ChatGPT or another LLM how to solve this issue, and then just pasted its response into the comment box. That isn't useful.

@kelseafunwi Sure, welcome. Take a look at our guide to contributing to Zulip: https://zulip.readthedocs.io/en/latest/contributing/contributing.html and in particular the steps here: https://zulip.readthedocs.io/en/latest/contributing/contributing.html#picking-an-issue-to-work-on

I thought you require proper documentation of the issue how it is solved. Also ChatGPT cannot read such big code lines and big project files.

[kelseafunwi]

I see why you were saying the code he gave was generated by AI 😂, I've been going through the codebase for about 5 hours now and haven't really seen how to get to that point. Still to continue working on it by evening.

Hopefully, i'll get an understanding of that part of the code soon.

[gnprice]

Yep, finding one's way for the first time around any given codebase takes some effort 🙂. We have a little bit of advice on how to do that effectively in the section you're already reading:
https://zulip.readthedocs.io/en/latest/contributing/contributing.html#picking-an-issue-to-work-on
and more detailed advice in this other section:
https://zulip.readthedocs.io/en/latest/contributing/contributing.html#flutter-based-mobile-app

[gnprice]

@shkshreyas Look, I've tried LLMs. I know how to point widely-used LLM tools at our codebase and ask them to do a task, and I know that the typical resulting output is in exactly the style of what you posted.

It's true that their output might not be good. In particular the LLMs have a tendency to make stuff up. That's another thing they have in common with the text you posted: the supposed "existing code" in that ComposeBoxState build method doesn't look much like anything in our actual codebase. It's a plausible imagining of what a simple compose box with topics might look like… but it's not something you would write if you, as a human, had actually read the relevant existing code in Zulip.

If you're going to try to lie to me, it doesn't make sense to interact further. Please find other projects to engage with as you learn how to work in a codebase and to produce good software. And if you choose to use LLMs in doing so, I recommend being honest about it.

[Gaurav-Kushwaha-1225]

Hi everyone,
I have understood the problem, but I'm doubting the solution you have suggested.

Like, instead of requesting focus on the topic field when the compose box is tapped, shouldn't we make it a necessity for the user to enter something in the topic field before they can send the message, and disable the send message button until then?
Or maybe fill the topic field by default with a specific topic whenever it becomes empty (for eg. in the beginning when compose box is tapped) as this also happens Zulip web app where it changes to the general topic by default.