Hi @OTichonova! Something could fail when the user tries to post the new topic. Can you tell us what this should look like? I would categorize these into two situations: No internet connection and something messed up on the server side. Here's a screenshot of both cases in our current talk page:

No interrnet connection

Server-side issue:

Hi @OTichonova! We did engineering sync on this a couple of days ago, and had these questions / comments:

1. It may be smoother technically if we prompted for login/signup immediately as they land on this page and before they type any message. This we way don't have to worry about saving their draft while they are logging in, and users' don't have to worry about losing their draft if they are navigated elsewhere to log in.
2. Formatting buttons - for bold and italic, my original simple approach (that is, bold and italic simply inserting tick marks on either side of the highlighted text) might be too simple to work well. The problem is that we can't have this simple code be context-aware, otherwise we're dipping into the CodeMirror code for our section editor, which we wanted to avoid because it requires a web view. So if you highlight text that is already bolded, the best we can do is add another set of bold ticks around it, which could muck up the formatting. We won't be able to tell if text is already bolded and remove the tick marks upon bold button tap. I still want to spend some timeboxed time spiking on this one, but just wanted to sound the alarm that we won't be able to undo already formatted text like our section editor does.
3. It looks like the API gives us topics in order of oldest-first. This means when they insert a new topic here, we'll need to refresh the topic list and scroll them down to the bottom so that they can see it. Is that okay? We can also change the topic sort order to newest-first from the app if you prefer to see it inserted at the top.

Hi @Tsevener!
Awesome thank you for the comments/questions.

1. Right, I am just slightly worried that putting the login/signup as they land on the page might a) have people think that they have to login to engage with the page b) and create an extra barrier for people to utilize the page (don't want them to abandon their flow).
   • How much more complicated is it to save a draft of the text?
   • After the contributor goes through the login/sign-up process will they be back on the page where they were before?
2. Okay sounds good.
3. Hmm so for this one I am still thinking what to do. For me, it is more logical to have the topics newest to oldest, but web does it the other way around. I will like to test this in the next usability test to make sure that editors/new contributors prefer that before changing it. Android has discussed this too and has added a sort option for the topics. So all that to say, lets keep it oldest to newest for now and I'll run it past the editing team to see if there is any particular reason why we should keep it like this.

Notes from engineering sync/task sync (addressing 1, 2, 3 comments above):

1. The plan is to allow user to write their message and propose login/sign up flow after they tap Publish. Present sign up / login flow (if they choose that option) on top of the new topic compose screen, full screen. Have user log in, don't dismiss the login / sign up screen until we're sure it succeeded (we may need a spinner somewhere if there isn't already a loading state). Once it succeeds, login/sign up modal will dismiss and user will be back to seeing their new topic compose screen. User will then need to tap Publish again to publish their new topic.
2. Did a little bit of asking around, and it sounds like Android is able to do a naive approach in their section editor (tapping adds tick marks, tapping again removes tick marks) without any RTL issues. I still want to prioritize this functionality later on and get the bulk of talk pages built first before adding this formatting bar.
3. Sounds good, we'll go with oldest to newest sorting for now and will insert the new topic in at the bottom. We won't get to this part for a while so there's time to change it if user testing indicates we should.

Part 1 - https://github.com/wikimedia/wikipedia-ios/pull/4308

Things remaining to develop:

• Fine print link handling
• Logged out flow
• User education modal

Things remaining to develop:

Logged out flow

Hi @OTichonova! I have a couple of comments about the logged out flow for this and T310291:

1. I'm going to have to match how our existing panels are styled, so I can easily reuse all of that logic. If you need to change any styling here it will update all of the current panels that we have. Here's what I have so far. Feel free to kick it back to us at the design review stage, but I just wanted to give you a heads up at this point before I open the PR.

2. I originally envisioned this as automatically publishing the user's new topic or comment after they completed the login or sign up flow. Unfortunately login can trickle out into many different paths (forgot password, password reset, two factor) and it's difficult for me to keep track of when it's all finally complete to automatically publish. I can spend more time on it if you feel strongly about it, but I noticed Desktop does not automatically publish (you are sent to a login screen, then returned back to your draft, where you tap the Add topic / Reply buttons). So for now I'm going with that flow - if the user isn't logged in when tapping Publish, they can log in or sign up, which will ultimately dismiss the login and sign up screens once they are successful. Then the user has to tap Publish again for it to go through. Let me know if that works for you, thanks!

Hi @Tsevener,
Thank you for the heads up!

1. Right, so I was thinking for consistency's sake, we should go off of the 'Log in to send 'thanks'' modal, (shown below) and have the top button say 'Log in or create account' and the quiet button say 'Edit without logging in' and avoid the stacked quiet buttons. New design shown below.

The 'thanks' modal inspo.	Proposed button tweak to the current modal

the user has to tap Publish again for it to go through

Okay, I think it's fine that it doesn't automatically publish it. Let's keep it that way.
Thanks!

@OTichonova Can do! Thanks for the quick reply.

Logged out flow PR: https://github.com/wikimedia/wikipedia-ios/pull/4359

Looking good on 7.0.0 (2003)